As we get more Darkstar information together for the tutorials and start actually implementing them, a question arose that I think is quite prudent. Part of the entire 15-minute out-of-the-box experience is taking a large and complex system and simplifying it for new users so that they can get in, get their feet wet, and end up with a flashy result; the goals being to get them interested in Darkstar and show off what it can do and how easy it is to do it. This has a couple implications. First, we want the user to actually see, write, and become familiar with the code. This is important because users eager to learn an exciting new technology will want to do just that: start coding. Let's say you go to some rock concert, see the guitarist hammering out a crazy solo, and suddenly decide, "Hey, that looks really cool; I want to try that." Initially, you aren't going to spend lots of time reading about how to play guitar; you're going to grab a guitar and start tooling around with it. Same idea. Second, we want everything, everything, to be easy and go as smooth as possible. To have a successful out-of-the-box experience, you simply cannot lose the user's interest or create an experience that is uncomfortable and/or ungratifying. If we give them a task that is perhaps a bit too confusing or complicated, they will get frustrated, walk away, and find something else to do (It doesn't take long!). Also, if they spend too much time doing required tasks that deviate from actually working with Darkstar, we have a similar issue. We wrote the installer program for this very reason: simplify set-up and get people coding faster.
So we want to get people coding quickly and with as little hassle as possible. How do we accomplish this? In order to start coding with Darkstar, you're going to have to download and install Darkstar, create projects with build scripts, and create properties files. Also, in order to run your application you have to run the java virtual machine with a long list of specific but required arguements. Some of these tasks aren't trivial. Ideally, we don't bother the user with any of this. Instead, we provide everything and all the user has to worry about is code. We already dealt with the installation, but what about the rest? Even if we provide things such as build scripts for a project or shell scripts for running the application, at some point the user is going to have to do these things themselves. After all, these scripts would be specific for the situation and would probably not suit a generic programmer's custom needs. This little conundrum leads me to the question that I mentioned at the beginning of this post, and the question is this:
Striving towards simplification, how much are we willing to encapsulate from the user?
An idea that we are going with at the moment is the use of an IDE, namely NetBeans. We chose NetBeans for a variety of reasons. First, the Snowman project is written within NetBeans, and if we opted out of using it, we would have to re-write build scripts in order to remove the project dependency on it. Also, (and this is true for just about any IDE) it encapsulates building and running into one application, which is very nice. But what about the drawbacks? Well, we are adding a dependency to the tutorials. A rather big one, in fact. Users MUST have NetBeans or else they will have to spend a lot of time trying to convert over to another IDE (or not use one at all), which is ... undesired to say the very least. In addition, setting up a Darkstar project in NetBeans can be quite tedious, and this detracts from the user experience. There is a way around this, but I'll get to that in a second.
Remember that the user will eventually have to learn how to create their own projects from scratch. An option is to have the first tutorial explain this process. Have the user create their project (which, by the way, allows for a more open-ended choice on how to go about doing it, whether with NetBeans, Eclipse, Ant, etc.) and then start programming with darkstar. Okay, sounds reasonable.
The big reason we have been thinking about NetBeans over the previously mentioned option is because we don't want to have the user deal with any set-up. These tutorials are not just learning tutorials; they are a full out-of-the-box experience. And along with that comes the fact that getting darkstar out of it's metaphorical "box" - and doing it quickly - is a really big deal. While teaching the user about set-up from the get-go is useful, for our intents and purposes it ultimately comes second to grabbing users by the ears and tossing them directly into the briar patch.
Thus, we arrive back at NetBeans. I mentioned that projects still require some set-up. While this is true, it can also be done completely beforehand. Part of what I worked on today (or yesterday now, it's getting late) is setting up a project file that can simply be opened, built, and run immediately from within NetBeans. This, I believe, is really the optimal choice for what we are trying to accomplish.
So that's basically my thoughts and opinions on this whole project at the moment. If the final decision is to go with this format, I have a proposal regarding the tutorial arrangement that I would like to discuss.
All tutorials can exist within a main tutorial folder, in which they can be separated into folders for each individual tutorial, say tutorial 1, tutorial 2, etc. These are mainly just for organization and is something we've sort of been doing already. Within these will be the folders for the NetBeans projects. This is where things get different however. For each tutorial project, I propose we create two separate projects. The first one will be a blank project (or a partial project, depending on the tutorial) ready for the user. The second will be a completed tutorial. This is how 3DStudio Max organizes their tutorials, and I think it's very effective. The first blank project allows the user to start coding right away without having to worry about set-up. The other completed tutorial will give the user a reference to a completed project, and this has several purposes such as allowing the user to compare/contrast between thier own work to see if they made a stupid mistake or did something wrong.
On a side note, having the tutorials set up in this manner can also allow them to be packaged separately from Project Darkstar itself, like a demo. This isn't a proposal though; just a thought.
Alright. So basically there's one basic point to my entire post today, and it isn't necessarily to treat users like they have the attention span of a goldfish, although that's basically the idea. To sum everything up: using NetBeans, including pre-made project files, and neat organization is key to a successful out-of-the-box experience. And that, my friends, is my two cents worth.
Wow, that was a long post. Well, for me at least. I like ending posts with an interesting video, usually something especially thought-provoking and intelligent that others may very well enjoy.
1 comment:
lol
Post a Comment