As typical for an INTJ, I like to make my processes more efficient. To be honest, I'll redesign the process before working on the project. Why, because the process affects the project. The less time focused on the tools and process problems means less wasted time and more focus on the project goals. This is true for both education and games.
Most of today I've been going over the possibility of making Fire Fox act like Flock. There is a lot I like about Flock, but some things I miss about Fire Fox. So, I looked at my tools, started doing some tune-up work and now am testing some of that work. For this post I am using Scribefire like I used Flock to post Social Gaming and Learning. Honestly, I like Scribefire more than Flock's blogging tool, though neither seems to have a way to create and save blog post templates. However, Scribefire has a "notes" feature that could be used to save the template.
Anyways, the point is that wonderful tools in a general sense can be horrible tools in the personal sense. I've blogged about Iteration and Prototyping, and linked to articles that touch on using the right tools. Well, this post is specifically aimed at using the right tools.
While looking for add-ons to Fire Fox I installed and uninstalled some multiple times. The initial settings are always something to look at when picking up a new tool, or add-on in this case. What I found was that some of the add-ons were not well suited to me without customizing the settings. One color codes the tabs, but starts out as just randomly coloring, rather than site based color coding. A little customizing and I now have URL based color coded tabs. That customizing process is akin to an initial tune-up, but that doesn't mean it will always be working great for you. That's when more tune-ups can help. Organization systems are prone to this. In programming there is even a name for it, refactoring. Tools also have this problem, as they commonly have settings and options to customize them to you. Thus, as you change over time, the settings may need to change to better fit you.
The way to figure out when, and what kind of, tune-ups are needed is testing. That's what I'm doing with this post, to test the the new tool I've installed. At this point it seems to be doing fairly well, and like I said, I like it more than the blogging tool in Flock. I'm a little curious about what will happen when I try to publish this, but till I try I won't know. My guess is that it will work, since the preview function said it published, and deleted, a version of this post to set up the preview function for this blog. If it does work, I think I'll pester some people like Jim Groom, Stephen Downes and others working with interesting tools for educational blogging, as Scribefire would work well for research paper type blog posts. This may become a favorite tool of mine for just that kind of posting.
Some of you might notice how this parallels iterative design practices. Seems to me that it's an iterative process refining your tools, their uses and their settings. That's just fine for me. I like experimenting with ideas that might improve how I do things, though one should be careful of volatile situations, for obvious reasons.
After all that, yes I know it's not much, I will point out one of the most important parts of dealing with your tools; take the time to give them tests and tune-ups. It seems obvious now, but when you are done with a project, or starting one, you should take some time for this. After a project is done you should have information from the project, and hopefully more coming in as user feedback, to work with. At the start of a project you should make sure your tools will be able to do the basics of what you want, and should be easy enough to create a mock-up with. If you can find somebody who knows what they are doing, and are willing to help, it would likely help your project to have them advise you on how to improve your process. Sometimes it is a little change, with no math based proof, that will improve team moral and the quality of the project.
One aspect that shouldn't be overlooked is user participation in the process. User feedback is better than technician, designer and developer feedback. Having real users try your project results will give you the most relevant testing results. They may not be very clear, but they will be relevant. This is especially important in the game and education fields, as user perceptions and results are the main focus.
Have fun, spread the word and tell me what you think,
Igen Oukan
Most of today I've been going over the possibility of making Fire Fox act like Flock. There is a lot I like about Flock, but some things I miss about Fire Fox. So, I looked at my tools, started doing some tune-up work and now am testing some of that work. For this post I am using Scribefire like I used Flock to post Social Gaming and Learning. Honestly, I like Scribefire more than Flock's blogging tool, though neither seems to have a way to create and save blog post templates. However, Scribefire has a "notes" feature that could be used to save the template.
Anyways, the point is that wonderful tools in a general sense can be horrible tools in the personal sense. I've blogged about Iteration and Prototyping, and linked to articles that touch on using the right tools. Well, this post is specifically aimed at using the right tools.
While looking for add-ons to Fire Fox I installed and uninstalled some multiple times. The initial settings are always something to look at when picking up a new tool, or add-on in this case. What I found was that some of the add-ons were not well suited to me without customizing the settings. One color codes the tabs, but starts out as just randomly coloring, rather than site based color coding. A little customizing and I now have URL based color coded tabs. That customizing process is akin to an initial tune-up, but that doesn't mean it will always be working great for you. That's when more tune-ups can help. Organization systems are prone to this. In programming there is even a name for it, refactoring. Tools also have this problem, as they commonly have settings and options to customize them to you. Thus, as you change over time, the settings may need to change to better fit you.
The way to figure out when, and what kind of, tune-ups are needed is testing. That's what I'm doing with this post, to test the the new tool I've installed. At this point it seems to be doing fairly well, and like I said, I like it more than the blogging tool in Flock. I'm a little curious about what will happen when I try to publish this, but till I try I won't know. My guess is that it will work, since the preview function said it published, and deleted, a version of this post to set up the preview function for this blog. If it does work, I think I'll pester some people like Jim Groom, Stephen Downes and others working with interesting tools for educational blogging, as Scribefire would work well for research paper type blog posts. This may become a favorite tool of mine for just that kind of posting.
Some of you might notice how this parallels iterative design practices. Seems to me that it's an iterative process refining your tools, their uses and their settings. That's just fine for me. I like experimenting with ideas that might improve how I do things, though one should be careful of volatile situations, for obvious reasons.
After all that, yes I know it's not much, I will point out one of the most important parts of dealing with your tools; take the time to give them tests and tune-ups. It seems obvious now, but when you are done with a project, or starting one, you should take some time for this. After a project is done you should have information from the project, and hopefully more coming in as user feedback, to work with. At the start of a project you should make sure your tools will be able to do the basics of what you want, and should be easy enough to create a mock-up with. If you can find somebody who knows what they are doing, and are willing to help, it would likely help your project to have them advise you on how to improve your process. Sometimes it is a little change, with no math based proof, that will improve team moral and the quality of the project.
One aspect that shouldn't be overlooked is user participation in the process. User feedback is better than technician, designer and developer feedback. Having real users try your project results will give you the most relevant testing results. They may not be very clear, but they will be relevant. This is especially important in the game and education fields, as user perceptions and results are the main focus.
Have fun, spread the word and tell me what you think,
Igen Oukan
View Blog Reactions
0 comments:
Post a Comment