Skip to main content

Wizards are for Dungeons and Dragons

Jeez - I go heads down into work for 2 days and missed this great post on Thursday by Joe Wilcox on the Microsoft Monitor.

Whenever I give Visual FoxPro training, I almost always skip over the Wizards except for one: the reporting wizard but for the most part I agree with this article.

Instead, the Builder or Helper approach is much more straight forward. A Wizard typically "does it all" but how many steps make up a good Wizard UI?

Traditionally, Wizards have at least three screens: a welcome, a to do and a finish. Well - get rid of the Welcome and now you're left with two. In those cases, I think it makes very good sense to get rid of the Wizard - it's simply not needed. The Add Hardware wizard sometimes really bugs me - it says 'I'm hear to add your hardware" and then almost instantly "I'm done." Why not just add it automatically?

I used to like putting in Wizards for some of my more advanced configurations - because they needed to use users specific questions. If you have 50 options that need to be set, you likely don't need to ask about each one - you only need to ask about 5 to 10 questions - but it could almost be like the Property pages these days - where you have a Basic property that shows 10 options and then an advanced that shows all of the options.

A Wizard approach to 50 questions might have 10 different steps - and that's just way too many. The original Foxfire! setup wizard had a great feature - it SAVED the configuration and allowed users to come back to it before committing it. But now, in recent versions, the tools themselves have gotten better so they only need one or two steps and if that's the case, why do you need a Wizard at all.

Wizards used to be great when the underlying tools were simply too complicated to use. But now with plug and play and developers actually taking the time to make that lower level much more accessible - they are effectively a hindrance.

The bigger problem I have with Wizards is that they "do it all" and don't tell you what they did. Builders , at least in the VFP world, do something for you but what they did is obvious.

I'm sure there are some exceptions that one could find but I don't see why a better Wizard UI would have two approaches:

1. A Basic and advanced viewing of settings
2. A Builder approach. I don't think anyone wants to hand-write the code generated by the RI Builder but it's great that you have EASY access to it afterwards.

You tell me - do you use a Wizard approach in your applications for hard to do stuff?

Take my poll and let me know.

Microsoft Monitor: Wizards are for Dungeons and Dragons

Comments

Popular posts from this blog

Merry Christmas

Whether you celebrate now, have already celebrated your past holiday, are planning to, or not, I hope you find yourself surrounded by family and those you love during this holiday season and are able to remember fondly those who are not with you. We often find ourselves buried in work, or too distracted by other problems, to share and remember a few moments with those closest to us. So many of us are separated by huge distances, we often find it easier to focus on those who are out of arm's reach yet so easy to connect with online, instead of those who are right beside us. So do yourself a favour, put down the keyboard (stylus, mouse, etc) and spend that time. I know I will. Merry Christmas. Powered by ScribeFire .

From Writing to AI: the pattern repeats itself

When I was ten years old, my dad bought a computer and, thanks to an advertising supplement in a Superman comic I read, it was a TRS-80. A month later, he dragged the entire family (my mom and brother were not the most enthusiastic) to a class at Radio Shack teaching how to use microcomputers. At the time, I understood why my mom wasn’t that excited: the computer was yet another gadget in the house. But today I find it fascinating. My mother went to Vassar in the 50s. She learned how to type — not a common skill at the time — but it opened doors. Her ability to communicate effectively led her to a career in adult education and later communications work with the CBC (Canadian Broadcasting Corporation). This isn’t a nostalgia post. Today, the ability to use artificial intelligence, be it through Copilot or simply writing the right prompt, is becoming a critical skill. But is it really that novel? In the 1500s and 1600s, the printing press gradually made reading accessible beyond cler...

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction...