June 09, 2008 | Comments: (0)
Over on the Advice Line blog, a reader who signs himself "Need help from Bill Gates" asked Bob Lewis about an upgrade project from a Windows application using MDI to the .Net Framework. The architects he talked to pooh-poohed Windows Forms as "old school" and pushed Web applications, Windows Presentation Framework, and Silverlight. Bob said "it depends" and suggested another conversation with the architects about fashion vs. style.
Here's my answer:
Dear Need-Bill ...
You need to talk to different architects, ones who will listen to what you want and analyze what you need instead of pushing the latest technology because it's glitzy.
Web applications have an advantage over desktop applications when it comes to installation and accessibility, but they aren't as responsive as desktop applications at this point. Windows Forms (WinForms) is the right technology if you want to build a Windows desktop application with the .Net Framework that will provide maximum productivity to people who use the application heavily, especially if they enter lots of data.
Windows Presentation Framework (WPF) offers additional graphical capabilities for desktop applications, but requires more in the way of hardware than WinForms to run well. I'm not sure your customers need or could benefit from the advanced graphics, and they might not want to upgrade their computers to run it.
Silverlight is a rich Internet application technology. It implements a subset of WPF as a Web browser plug-in.
Beautiful things can be done with Silverlight rich Internet applications, but you'd need Silverlight 2.0 if you wanted to build one that would be useful for line-of-business or data entry: Silverlight 1.0 doesn't even have a native text input control. Silverlight 2.0 has not yet been released: it is still being beta tested, and beta 2 was just released on Friday.
Posted by Martin Heller on June 9, 2008 08:03 AM
January 01, 2008 | Comments: (0)
UI Design: Beauty, or Consistency?
For years, one of the big selling points of Windows was its consistency: once you've learned how to use one Windows application, you've learned a lot about using most Windows applications. You could say essentially the same thing about Mac OS, KDE, and GNOME, and for that matter about Java/JWT and Java/Swing applications.
If the user expects to see File, Edit, View, and Help menus, your application will be easier to learn if those menus are present. If the user expects to see a toolbar and is familiar with a specific set of toolbar icons, then you can improve your application's usability by meeting those expectations: you're providing instant familiarity by adhering to standards.
The objections to these standards, which I most often hear from designers, are that they lead to ugly, boring applications. But often, the alternatives that they deem beautiful and exciting turn out to be hard for users to learn. I have sometimes heard myself sneering at these attempts as "eye candy," although I do appreciate attractive visuals.
In its day, Visual Basic led to a run of horribly designed user interfaces, as well as some very nice ones, by giving designers more power. Flash has done the same for Web sites, and I fear that Windows Presentation Framework will be taking junky eye candy to new levels on Windows.
What's your take?
Posted by Martin Heller on January 1, 2008 02:40 PM
November 27, 2007 | Comments: (0)
My discussion of software surprises on Saturday reminded me about the Law or Principle of Least Astonishment, also called the Law or Rule of Least Surprise. This certainly goes back to the early days of Unix, if not before: it is discussed in The Art of Unix Programming, by Eric Raymond, which is online here.
I'm convinced that the originator of the name of this law had a Physics background. The name is strikingly similar to the Law of Least Action, which is the basis of Lagrangian and Hamiltonian mechanics.
Tracking down the origins of the Law of Least Surprise reminded me that I had on my bookshelf at work signed copies of The Tao of Programming and The Zen of Programming, given to me by the author, Geoffrey James, when we were in the same Tai Ji Quan class some years ago.
The entire English text of The Tao of Programming is actually online. Half the pleasure of the book is the Chinese on the facing pages and the layout; that has been lost in the online version. Even though I've studied Chinese and still have my dictionaries, I've never bothered to translate that Chinese -- and I've never asked Geoff what I'd find if I did. I've also never asked whether he minded the online version of his book.
The passage on the 'Law of Least Astonishment' follows:
A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity.
A program should follow the 'Law of Least Astonishment'. What is this law? It is simply that the program should always respond to the user in the way that astonishes him least.
A program, no matter how complex, should act as a single unit. The program should be directed by the logic within rather than by outward appearances.
If the program fails in these requirements, it will be in a state of disorder and confusion. The only way to correct this is to rewrite the program.
Posted by Martin Heller on November 27, 2007 07:45 AM
November 24, 2007 | Comments: (0)
In Software, Surprises are Usually Bad
In life, surprises can be good or bad. In software, surprises are usually bad.
This was driven home to me the other day when I was arranging some music using Finale 2008, a capable but complicated musical notation program. I've been using Finale for over a decade, but only occasionally.
A new version of Finale comes out every year. I upgrade at least every two years. Each new version has more features, and improvements to the user interface.
Improved user interfaces are usually exactly that, but only once you get used to them. It's the change itself that's a problem. Anyone who's upgraded from Office 2003 to Office 2007 or from Windows XP to Windows Vista knows what I mean.
I was adding choral accompaniment to a liturgical piece for cantor and keyboard. I started off by scanning the original arrangement into the program, and correcting the recognition errors. Then I wanted to add the choral staves between the cantor's line and the two keyboard staves. A wizard helped me create the Soprano, Alto, Tenor, and Bass staves with the correct clefs, but it added the choral staves at the bottom without giving me a chance to specify where I wanted them.
Fair enough. I saved the new version of the score, and with the Staff tool active I tried to drag the keyboard staves to the bottom and then evenly space all seven staves. I tried everything obvious, and got nowhere but frustrated: even when I did manage to get to the right view (this only works in page view), find the right handles (there are many, and it isn't obvious which ones are for staves and which are for staff groups), and drag the keyboard staves to the bottom, when I applied automatic spacing they would pop back to their original position.
I pulled up the Finale help, spent half an hour going through everything remotely relevant to staff placement, and was none the wiser. Finally I searched online, and found an article in the Finale knowledgebase called Changing the order of existing staves in a song that told me what I needed to know: Finale needs to be explicitly told to change the staff order before the respacing step. The menu item is Staff | Sort Staves. I had no idea it was necessary.
I must not be the only composer or arranger to have this problem, because the knowledgebase article reads as though it were revealing a religious mystery:
To change the order of the staves is a three step process.
To begin you will need to be in Page view using the Staff tool. Grab the handle of the stave you want to move and drag the stave to where you want it. This will not move any of the other staves, however it will look crowded.
Then go to the Staff menu and click on Sort Staves. This won't change how anything looks but it is an important step before we run the staff spacing.
Now go to the Staff menu and choose Respace Staves. In the Respace staves box you will probably not want to change any of the settings, click OK.
In some rare cases we have found that you may have to also reset the System Margins then in the Page Layout tool.
Now I have to figure out how to reduce the size of the keyboard staves so that I can fit two systems per page. It's got to be here somewhere...
Posted by Martin Heller on November 24, 2007 08:56 AM
TOP STORIES
ADDITIONAL RESOURCES
- Best Practices for Successful SOA Governance
- Application Grid: Oracle's Vision for Next-Generation Application Servers and Infrastructure
- Do you have the power to resolve technical issues with one call?
- PS Series Best Practices Deploying Microsoft(R) Exchange Server 2007 in an iSCSI SAN
- Building a Highly Reliable SAN
- Enhancing Your IT Environment with SnapShots
