Monday, March 31, 2008
Sorry for the inconvenience.
Thursday, March 27, 2008
As you all know, smooth scrolling didn't make it into Flex 3. You can find some info and a head start at Alex's Flex Closet. If you are currently working on implementing this for datagrids (horizontal and vertical scrolling) and lists with variableRowHeight="true" that would be awesome. If you aren't already working on it but like a good challenge, I'm sure the rest of the Flex developers of the world would appreciate it.
If anyone has something more tangible to offer in reward feel free to comment here.
It tells me when it last did it so I can be sure that if something went wrong and I lost my internet connection or my machine crashed, all but the last few words would be safe. If I click SAVE NOW, I get this so I can differentiate when I saved vs. an auto-save.
Notice that the text saying when it was saved is not modal, so I can happily ignore it if I want. This is much better than an Alert saying the same thing since you can't ignore an Alert.
Usually the argument against this goes like this "We can't decide when the user should save" or "What if the user doesn't want to save?" In actuality, it is safe to assume that the user always wants to save. After all, how often do you spend a bunch of time writing something and then not want to save it? You may infrequently, discard changes but that certainly happens much less often. Since it happens so infrequently, Blogger has no way to not save. This was no doubt a concious decision based on knowledge of real users' goals.
Now, some applications may need the ability to not save. But, that doesn't mean that you can't have auto-save. One solution would be to store the last manually saved data in a secondary location until the next manual save. Then if you wanted to revert to your last save after auto-saves have occured, you could simply retrieve it from that secondary location. If revert is never needed, then you could just throw that data away when the session ends.
I can already hear the arguments now. "That would be very difficult to implement", "We should spend our time on REAL features", "How would referential integrity be maintained?", etc.
In some applications this not trivial. But, as usual, the arguments against rarely mention Jane Smith, the professional writer. Remember, software is meant for humans to use to solve their problems. We can't leave them out of the equation.
Wednesday, March 26, 2008
Now, assuming that the error had something to do with the open Word document, you have to wonder why the error message didn't say something like "You cannot close this spreadsheet while the embedded document is open". Obviously at some point in the development, someone decided that "Reference is not valid" was going to be an appropriate message to show Bob Smith the accountant tracking inventory. Even as a developer, I have no idea what that could mean. But, since the only choice is "OK", I guessed that I should click it. After that, nothing seemed to happen, so I decided to try quiting Excel entirely. And then...
Ummm..... huh? What do you mean you can't quit Excel? Am I not in control of my own computer. I said quit and and you should quit. Again, somewhere in the development process someone decided that it would be ok to be in a state in which the application cannot stop. Like a bus with no brakes, all we can do is honk the horn and tell people we can't stop.
I assumed that the problem has to do with this Word document. So I just hit "OK" (By the way... things DO NOT feel ok at this point). I close Word and then try to quit word again and get...
... hmmm... So now things are not looking good. So I do what everyone would do and open up Task Manager, click on the Process tab, find excel and click End Process. So, if I could "quit" Excel, why did Excel say it couldn't?
This is a case where these messages were probably not expected to occur, but even if there is an unlikely chance of it, a small amount of time could have been spent to at least give some idea of why the program was in this state. A few minutes more, and the message could have explained how to recover, albeit a round about way. Almost anything would have been better than these messages.
Before all the Mac followers start proclaiming that this is why Microsoft is evil, let me just remind you of this:
Watch out... its gonna blow!
In Apple's defense though, most of the time they at least did a better job of telling you how to get past your problem.
However, the bomb icon is a bit disturbing and there is really no point in saying "unimplemented trap".
The bottom line is that if you are going to say something to the user about an error condition, make sure it is in a language they can understand. "Referenence Error" and "Unimplemented Trap" might as well be in Greek to most people.
Tuesday, March 25, 2008
However, I think this trend is likely to release the browser of its responsibility of an application platform. Since it was never intended to be that platform, all the complexity that went along with it just detracts from its value as a platform for retrieving and displaying information. In the role of information delivery I think the browser is a wonderful thing. Features like the new WebSlices and Activities features of IE8 are information-centric features.
Just like any employee, if we let the browser do the job it was hired to do, it can really excel at it.
Having built many AJAX and Flex applications I personally feel that it is harder to deliver as rich a user experience using AJAX as with Flex. My gripe with the article however, is that the synopsis specifically talks about power users as being disappointed. The reality is that only a small percentage of users of most applications are ever power users. Similarly, only a small percentage are novice users for very long. The majority of users are intermediate users. So be careful about choosing a technology based on the wrong population.
Sunday, March 23, 2008
I don't eat in the cafeteria much. In fact I almost never eat in the cafeteria. I do, however, get a drink at the cafeteria daily. Up until last week, the process was very simple. I could go to the soda machine which had the cups, lids and straws kept in a plastic dispenser directly to the right of the soda machine. So the process of getting a drink was simple. Pick up the cup, fill with ice and soda, retrieve a cover from the dispenser, get a straw and off I go.
One day I noticed there were no straws next to the machine. I assumed the dispenser needed to be refilled. I asked someone for more straws and he quickly walked out into the the area where all the tables are (the soda machine is in the area with the kitchen and salad bar) and opened the cabinet below the counter where the utensils and napkins were stored and pulled out a box of straws. I took one and off I went.
Ever since that day, there have been no straws near the soda machine. They are now stored along side the napkins and utensils.
So here is the problem. The straws appear to now be kept in the current location for the sake of keeping them near the place where the extra stock is stored, instead of where they are actually needed. This is often a problem in software development as well. How many times have you heard a developer say "it is easier to put the button here" or "we have to do it this way for techincal reasons." There may be times when it is techincally challenging to make software do what is best for its users. However, the problem could have easily been solved before it was a problem, by thinking about how it might be used.
One could argue that many people who come to the cafeteria are there to eat so they will likely need napkins and utensils as well. However, the is a whole other type of visitor, that frequent the cafeteria. This is also a common problem in software. As developers, it can be very difficult to think about anything other than "The User". The problem is "The User" is a combination of every possible type of user which leads to an interface created for a person that doesn't really exist. If the cafeteria manager thought about "customers here to eat", "customers here for a snack" and "customers here for a beverage" then it would be obvious that things should be set up to accomodate each of them. For example, customers planning to eat would likely need utensils, napkins and straws. The current set up would work well for them. Customers who came in just for coffee or a soda would probably never need to visit the seating area at all. Placing sugar, creamer, straws and napkins right by the checkout would make a lot of sense.
We can do this in software design as well by thinking about the types of users the system might have. The point is to make sure you are supporting the real users of your software so that you don't make the system difficult or ineffecient for a significant amount of them.
If you are wondering what that has to do with the User Experience of software, let me set the stage. How many times have you been prompted with an Alert box telling you that some was "ok". This might be something like "Your changes were saved successfully" or something to that effect. The reality is that, while it would be appropriate to Alert the user when changes failed to be saved, it isn't appropriate to say "everything's ok" with the software equivalent of an alarm going off.
Homer's invention illustrates the absurdity of using the wrong method of communication in the "real world", however, sometimes we forget that the same care must be taken when selecting a method to communicate in software.
A better way to alert the user that something was successful would be to display a message, perhaps next to the save button, saying "Changes were saved at 12:34 pm" This notifies the user that the changes were saved without forcing the user to acknowledge what a great job the software did doing its job. It also adds more value because it indicates the last time changes were saved which may be important in some applications.
So lets leave the "Everything's OK alarm" to the cartoons... and I don't want to see any software equivalents of the "makeup gun" either.
Wednesday, March 19, 2008
It has been a long time since I worked on a Mac, so I can't even remember if they have any equivalent feature. If so, I would like to add it and would need some help testing it. If not, I would appreciate somone with a Mac testing it out to make sure I don't inadvertantly cause a bug that isn't apparent on Windows.
If you are interested, email me at rob (at) mcgraphix (dot) com
Monday, March 10, 2008
Thursday, March 6, 2008
Apparently Steve Job's is either a complete nut-job or a genius beyond all of our understanding. Ordinarily I would say that he is making a huge mistake, but for some reason he seems to pull off some long shots.