Monday, November 5, 2012
Upgrading software
Briefly, upgrade your software only when you want to take advantage of new features or security/stability fixes. That seems obvious, but a lot of people (especially people new to the idea of maintaining a software system) still think that "bleeding-edge" is the way to go, when that just isn't the case. There's nothing to be gained by putting your system in an unstable state at a whim or for the vacuous accomplishment of having the newest thing.
Furthermore, when you do upgrade your software, make sure you have a path back to the previous version so that if something doesn't work well with your system (and there will definitely be times this happens), you can revert without too much hassle. Too many times have I made some install that didn't have a sane un-install procedure--files flying all over the file system, and the only record of where they were supposed to go in a binary executable. Yuck. Avoid using binary executables for setup when you can and it'll save you trouble. And for god's sake, don't make them for your software, but make an install shell script if it wouldn't inconvenience your users. Sure theres the problem of platform incompatibility that comes with that approach, but that's true in any cross-platform system, and there are other ways of dealing with those problems.
Remember, remember the 5th of November...(tee hee)
~~~~
Saturday, November 3, 2012
Adaptive UX
Adaptive user interfaces (AUI) attempt to change to better suit their users. They typically start in some default state defined by the system designer. A user gradually adapts the interface to himself through a negotiation process undertaken during software usage. My first impulse is to reject this sort of interface for lacking consistency, but let's make a brief listing of the requirements for an adaptive UI in a multi-user system. (The multi-user stipulation is aspirational, but presents some considerations that must be made even in single user systems)
Mainly, my concern with this type of interface is that it doesn't allow for users from one instantiation of the system to use another without recalling to himself the initial set-up for the system. That kind of hiccup may only come up with multi-user systems and public terminals, but I think it would be useful for, say, the military to be able to switch out systems without the users needing to retrain the systems to their particular set of optimizations and preferences. There's also the consideration of establishing a common interface between systems. If each user can change the interface dramatically, there's no hope of standardization. Of course, we can say that each system has its own idioms and should be open to specialization for that system; however, for a class of systems that I'm interested in which may be called "general purpose" there is a great potential for making all uses of the system intuitive with a minimum of training. That is my goal anyway: to accelerate the rate at which we can come upon unfamiliar systems and become adept at manipulating them, removing many of the crude attempts at personalization and real-world analogy that plagued interfaces in the '90s and 2000s when computer use became more widespread.
~~~~
Mainly, my concern with this type of interface is that it doesn't allow for users from one instantiation of the system to use another without recalling to himself the initial set-up for the system. That kind of hiccup may only come up with multi-user systems and public terminals, but I think it would be useful for, say, the military to be able to switch out systems without the users needing to retrain the systems to their particular set of optimizations and preferences. There's also the consideration of establishing a common interface between systems. If each user can change the interface dramatically, there's no hope of standardization. Of course, we can say that each system has its own idioms and should be open to specialization for that system; however, for a class of systems that I'm interested in which may be called "general purpose" there is a great potential for making all uses of the system intuitive with a minimum of training. That is my goal anyway: to accelerate the rate at which we can come upon unfamiliar systems and become adept at manipulating them, removing many of the crude attempts at personalization and real-world analogy that plagued interfaces in the '90s and 2000s when computer use became more widespread.
~~~~
Friday, November 2, 2012
$300 prosthetic arm
http://money.cnn.com/video/technology/2012/11/01/ts-prosthetic-arm.cnnmoney/index.html?source=cnn_bin
~~~~
~~~~
Saturday, October 27, 2012
Country rock is pretty cool
Recently found myself a fan of Jason Charles Miller (youtube, homepage). I think I'll explore this genre a bit more.
On another note, I hope to have more long-form posts pretty soon. Have a few drafted posts that need a rereading/polishing.
~~~~
On another note, I hope to have more long-form posts pretty soon. Have a few drafted posts that need a rereading/polishing.
~~~~
Tuesday, October 23, 2012
state and interface
I wonder to what extent you can impose a stateless interface on a system which has an underlying state.
As an example, I might have a "repeat playlist" option built into my music player. There is clearly a state here since when the player is in "repeat mode" it will repeat the track, otherwise not. Typically this would have some sort of toggle item in settings. The other option though is to just give two options "repeat mode on" and "repeat mode off" in the same menu, juxtaposed, with the implication that selecting either one will leave the system in the named state, regardless of what it was before selecting the menu item.
There may be limitations to this when the possible states aren't easily flattened out like in setting some continuous quantity. In general though, I prefer absolute state markers to toggles because they can be engaged with, paradoxically, more certainty and less knowledge of the system-- unlike with mute toggle buttons--what's up with that shit?
~~~~
As an example, I might have a "repeat playlist" option built into my music player. There is clearly a state here since when the player is in "repeat mode" it will repeat the track, otherwise not. Typically this would have some sort of toggle item in settings. The other option though is to just give two options "repeat mode on" and "repeat mode off" in the same menu, juxtaposed, with the implication that selecting either one will leave the system in the named state, regardless of what it was before selecting the menu item.
There may be limitations to this when the possible states aren't easily flattened out like in setting some continuous quantity. In general though, I prefer absolute state markers to toggles because they can be engaged with, paradoxically, more certainty and less knowledge of the system-- unlike with mute toggle buttons--what's up with that shit?
~~~~
Control Your Data
This is just a bit of a reminder to myself to always define my data format manually.
Relying on Ruby to print out hashes in a specific fashion just hosed my test database :{
~~~~
Relying on Ruby to print out hashes in a specific fashion just hosed my test database :{
~~~~
Monday, October 22, 2012
Golden Rules of Interface Design
Important document. First saw it first semester of my freshman year.
Reproduced below
1 Strive for consistency.
Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout.
2 Enable frequent users to use shortcuts.
As the frequency of use increases, so do the user's desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user.
3 Offer informative feedback.
For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.
4 Design dialog to yield closure.
Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.
5 Offer simple error handling.
As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.
6 Permit easy reversal of actions.
This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.
7 Support internal locus of control.
Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.
8 Reduce short-term memory load.
The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.
~~~~
Reproduced below
1 Strive for consistency.
Consistent sequences of actions should be required in similar situations; identical terminology should be used in prompts, menus, and help screens; and consistent commands should be employed throughout.
2 Enable frequent users to use shortcuts.
As the frequency of use increases, so do the user's desires to reduce the number of interactions and to increase the pace of interaction. Abbreviations, function keys, hidden commands, and macro facilities are very helpful to an expert user.
3 Offer informative feedback.
For every operator action, there should be some system feedback. For frequent and minor actions, the response can be modest, while for infrequent and major actions, the response should be more substantial.
4 Design dialog to yield closure.
Sequences of actions should be organized into groups with a beginning, middle, and end. The informative feedback at the completion of a group of actions gives the operators the satisfaction of accomplishment, a sense of relief, the signal to drop contingency plans and options from their minds, and an indication that the way is clear to prepare for the next group of actions.
5 Offer simple error handling.
As much as possible, design the system so the user cannot make a serious error. If an error is made, the system should be able to detect the error and offer simple, comprehensible mechanisms for handling the error.
6 Permit easy reversal of actions.
This feature relieves anxiety, since the user knows that errors can be undone; it thus encourages exploration of unfamiliar options. The units of reversibility may be a single action, a data entry, or a complete group of actions.
7 Support internal locus of control.
Experienced operators strongly desire the sense that they are in charge of the system and that the system responds to their actions. Design the system to make users the initiators of actions rather than the responders.
8 Reduce short-term memory load.
The limitation of human information processing in short-term memory requires that displays be kept simple, multiple page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions.
~~~~
Subscribe to:
Posts (Atom)