Opinions on Dialog Design?
-
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
I've made plenty of screens like that. I work (and worked) for meat processing factories. A piece of meat comes on a line, which has all sort of properties, like weight, multiple quality marks, color, birth-, slaughter-, and fattening countries... So the worker scans the label and I fill out all of those fields, if possible, but if slaughter country is in a list of countries then you can edit some field, if it goes to (or comes from) some country or even specific customer they have to fill out another property, if the quality is AA then... etc. The worker really needs to see all the information at once because they can't make informed decisions without all the data. I've had a screen where each piece of meat (the individual cuts) was a row in a grid and each row had about 100 columns and the state of each column depended on a combination of sales order, sales order line, loading order, loading order line, production order, production order line, and a plethora of master data (like properties on the specific product, customer, country or packaging). Those were screens with some thousand lines of if-else branches and some people knew all of them (mostly different laws per country and such) x|
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
Have you ever had a boss who placed unrealistic constraints on your work?
Not so much a boss as internal users. Our product is a commercial ink-jet printing system, and our application runs the machine. I do our user interfaces, which are the control panel for this $2M+ piece of equipment. My ongoing problem is this. The mechanical, electrical, chemical, and service engineers love adding decisions to the user's workload. They want the user to decide whether they want to use mode X or mode Y when performing process A. When performing process Q, should we stop when condition C23 or C27.2 is detected? In a running joke in the group, they always suggest "Can't you just display a popup?". This is on a machine that must have certain operations always available (like STOP) and displaying a modal message box or task dialog is only reasonable in very select cases. The more important issue is that the user is a machine operator, and he simply doesn't care; he just wants to print. I spend ¾ of my time figuring out how to not add buttons or knobs. Many times the decision they're asking for is for their own debugging purposes, so those get added to an engineering section of the UI that isn't displayed in customer installations. If the decision is one they make once for the customer installation, it's made part of the configuration loaded at startup. Most of the remaining decisions I have to present and place so that they don't interfere with normal operations, but are where the user will find if needed. Every so often I get lucky, and after taking a pick-axe to the engineer's brain, figure out how to make the decision within the application without involving the user. When sales/marketing and management get involved this is harder. They like to dictate a particular solution ("can't you just display a popup?") and if they don't see that, they throw a conniption because you haven't done what they've asked. The advantage of being a Wise Old Head is that you become adept at explaining the benefits of your solution over the one they mandated, and doing so in a way that smooths their ruffled feathers.
Software Zen:
delete this; -
Richard Andrew x64 wrote:
Have you ever had a boss who placed unrealistic constraints on your work?
Not so much a boss as internal users. Our product is a commercial ink-jet printing system, and our application runs the machine. I do our user interfaces, which are the control panel for this $2M+ piece of equipment. My ongoing problem is this. The mechanical, electrical, chemical, and service engineers love adding decisions to the user's workload. They want the user to decide whether they want to use mode X or mode Y when performing process A. When performing process Q, should we stop when condition C23 or C27.2 is detected? In a running joke in the group, they always suggest "Can't you just display a popup?". This is on a machine that must have certain operations always available (like STOP) and displaying a modal message box or task dialog is only reasonable in very select cases. The more important issue is that the user is a machine operator, and he simply doesn't care; he just wants to print. I spend ¾ of my time figuring out how to not add buttons or knobs. Many times the decision they're asking for is for their own debugging purposes, so those get added to an engineering section of the UI that isn't displayed in customer installations. If the decision is one they make once for the customer installation, it's made part of the configuration loaded at startup. Most of the remaining decisions I have to present and place so that they don't interfere with normal operations, but are where the user will find if needed. Every so often I get lucky, and after taking a pick-axe to the engineer's brain, figure out how to make the decision within the application without involving the user. When sales/marketing and management get involved this is harder. They like to dictate a particular solution ("can't you just display a popup?") and if they don't see that, they throw a conniption because you haven't done what they've asked. The advantage of being a Wise Old Head is that you become adept at explaining the benefits of your solution over the one they mandated, and doing so in a way that smooths their ruffled feathers.
Software Zen:
delete this;You could write the Caption: "Pop up brought to you by XXYYZZ decission". I bet that after one of those popups come to production the petitions of popups from that person or department would be drastically less pretty soon. And yes... I did something similar once. ;P :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Richard Andrew x64 wrote:
Have you ever had a boss who placed unrealistic constraints on your work?
Not so much a boss as internal users. Our product is a commercial ink-jet printing system, and our application runs the machine. I do our user interfaces, which are the control panel for this $2M+ piece of equipment. My ongoing problem is this. The mechanical, electrical, chemical, and service engineers love adding decisions to the user's workload. They want the user to decide whether they want to use mode X or mode Y when performing process A. When performing process Q, should we stop when condition C23 or C27.2 is detected? In a running joke in the group, they always suggest "Can't you just display a popup?". This is on a machine that must have certain operations always available (like STOP) and displaying a modal message box or task dialog is only reasonable in very select cases. The more important issue is that the user is a machine operator, and he simply doesn't care; he just wants to print. I spend ¾ of my time figuring out how to not add buttons or knobs. Many times the decision they're asking for is for their own debugging purposes, so those get added to an engineering section of the UI that isn't displayed in customer installations. If the decision is one they make once for the customer installation, it's made part of the configuration loaded at startup. Most of the remaining decisions I have to present and place so that they don't interfere with normal operations, but are where the user will find if needed. Every so often I get lucky, and after taking a pick-axe to the engineer's brain, figure out how to make the decision within the application without involving the user. When sales/marketing and management get involved this is harder. They like to dictate a particular solution ("can't you just display a popup?") and if they don't see that, they throw a conniption because you haven't done what they've asked. The advantage of being a Wise Old Head is that you become adept at explaining the benefits of your solution over the one they mandated, and doing so in a way that smooths their ruffled feathers.
Software Zen:
delete this;Gary R. Wheeler wrote:
I spend ¾ of my time figuring out how to not add buttons or knobs.
I think it was Pascal (the man, not the language) that said "I'm sorry I didn't have more time too write a shorter letter". People don't appreciate how much effort goes into making a smaller user interface. My story: I had to design a data acquisition system used on boats with many different sensors from many different manufacturers that rarely have been able to work together in a smooth combination. My choice was to make the configuration part quite complicated with many different options that had to be set correctly in order for the system to run. The data acquisition part, by comparison, was child's play with very few options or controls. The idea was that you would solve all the complicated problems while moored and with time on your hands while out on the water you had better things to do than fiddle with a finicky program. The program was a success and users loved it. Years have passed, many people have passed through marketing and bosses of many users have seen the program at trade shows. Each one came with a great idea like: "Can we see this in 3D?" (yes you could but than you cannot measure anything on screen) "Can we change color of each thing on screen?" (seriously? who has time to play with colors while running a boat?) and so on. On top of that, some of my colleagues added new features and sometimes, instead of putting the effort to make a sound design decision, they just went "oh, let the user decide what he wants. We'll just add check-boxes for the different options."
Mircea
-
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable.
Disaster in the making. If you have a hard time, how's the end user supposed to make sense of it? Maybe group the related controls that are on each page, so that what used to be one page, is now inside its own user control. So if the wizard had 6 pages, you have 6 user controls, all dropped on the same window as your boss wants it. As far as he'll be able to tell, it's all one page, but internally, at least, everything within each control will be wrapped in its own file/class. That should make it more manageable...? And just to mess with him - initialize the window so only the first control is enabled - disable (gray out) the other controls. Once those are filled in correctly and validated, disable control #1 and enable control #2, until you've gone through all user controls. Hey, he can't call it a wizard...
-
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
-
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
If the wizard evolution is linear it’s easy to present everything at once in one big menu of options. If all the possible options evolve into a tree (early options attract further changes down the chain ) showing all the options at once is difficult or impossible
-
Gary R. Wheeler wrote:
I spend ¾ of my time figuring out how to not add buttons or knobs.
I think it was Pascal (the man, not the language) that said "I'm sorry I didn't have more time too write a shorter letter". People don't appreciate how much effort goes into making a smaller user interface. My story: I had to design a data acquisition system used on boats with many different sensors from many different manufacturers that rarely have been able to work together in a smooth combination. My choice was to make the configuration part quite complicated with many different options that had to be set correctly in order for the system to run. The data acquisition part, by comparison, was child's play with very few options or controls. The idea was that you would solve all the complicated problems while moored and with time on your hands while out on the water you had better things to do than fiddle with a finicky program. The program was a success and users loved it. Years have passed, many people have passed through marketing and bosses of many users have seen the program at trade shows. Each one came with a great idea like: "Can we see this in 3D?" (yes you could but than you cannot measure anything on screen) "Can we change color of each thing on screen?" (seriously? who has time to play with colors while running a boat?) and so on. On top of that, some of my colleagues added new features and sometimes, instead of putting the effort to make a sound design decision, they just went "oh, let the user decide what he wants. We'll just add check-boxes for the different options."
Mircea
Mircea Neacsu wrote:
"oh, let the user decide what he wants. We'll just add check-boxes for the different options."
I've had to do that one far more often than I like. :sigh:
Software Zen:
delete this; -
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
Richard Andrew x64 wrote:
I had a boss one time who personally disliked wizard type interfaces in software.
It doesn't matter what your boss at the time (who I assumed was some sort of engineering manager) liked or didn't like. What matters is what the customer wanted. But I assume he probably wasn't smart enough to realize that. :( /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
Who is this boss who dislikes Wizards? I'll turn him into a toad if he is not careful.
Nothing succeeds like a budgie without teeth. To err is human, to arr is pirate.
-
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
I kinda prefer your former boss' UX philosophy, within reason. At the very least I prefer parallel settings rather than sequential, thprugh the usage of tabs for example. Of course in some situations having different steps makes it for a more intuitive interface (case in point: installation wizards) but, barring obvious distortions like what you mentioned, 'complete status display' is the way for me.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
I had a boss that asked me to remove an empty lines from all .c, .cpp files for better performance. Another boss liked to remove all comments from the source code, because good code should be self-descriptive. Finally, I managed to get an exclusive permission from both of them, to use empty lines and write comments.
-
Who is this boss who dislikes Wizards? I'll turn him into a toad if he is not careful.
Nothing succeeds like a budgie without teeth. To err is human, to arr is pirate.
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.
"F*** subtle", added Harry Dresden
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
-
As a general rule I dislike wizards as well, but I prefer to keep my dialogs simpler. The problem with wizard interfaces is they tend to be too many dialogs.
I am but a humble user. Yesterday I filled in a satisfaction survey for Argos, which claimed to be quite short. Some of the boxes I checked produced further lists of checkboxes. I started to lose patience, and eventually by experiment chose options which did not produce further checkboxes, in order to finish the thing. Some of the extra checkboxes included questions which had already been asked anyway.
-
I had a boss that asked me to remove an empty lines from all .c, .cpp files for better performance. Another boss liked to remove all comments from the source code, because good code should be self-descriptive. Finally, I managed to get an exclusive permission from both of them, to use empty lines and write comments.
-
Often my boss has "simple ideas" that turn into a real nightmare to realize, one of them was combining all config files of our Windows applications in C# into one master config file. Very handy for the guys of support was his reasoning, but not so handy to realize sadly. I made a clunky implementation with mutexes that will guarantee trouble in the future when new inexperienced developers will have to write applications for this mess ... :rolleyes:
I actually work for a guy like that. I live in the UI, and many times he'll walk in and ask for this "one little change" which is cataclysmic to my code base (I refuse to willingly bastardize the code). Interestingly, most of the time this is a requirements issue - he has an idea and hasn't completely conveyed to me what problem we're solving. The ultimate agile development ....
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
Okay, that's not design, it's just ignorance.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
Okay, that's not design, it's just ignorance.
Morons also need to make design. Otherwise, who will design Python programs?
-
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
Without more context, it is hard to know if your boss was correct or if you were correct in this instance. IMO every project needs to be tailored to its audience and the answer as to if step by step dialog boxes are applicable will vary greatly depending on the audience, the frequency a user will use the UI, and the learning curve just to name a few factors. Who I can say is most often wrong is the person who believes there is always a specific way to do something such as "always create a step by step dialog experience" or "never create a step by step dialog experience". And frequently more junior developers who don't yet have the lay of the land are more likely incorrect by following some "basic rule" someone previously taught them (or they developed) without educating them on the required context for the rule to apply. A good example in this case is the interview step through UI in Turbo Tax. For those of us who fill out a tax form once a year, this is a great interface. Imagine though if you worked at H&R Block and you filled this out every 30 minutes for 8 hours a day. That would be a horrible interface. Same job, same information, different user.
-
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
We converted most of our “wizard” UIs to tab paged UIs. Certain tabs only enable for certain conditions, etc. One summary tab for validation errors that navigate to offending tab + field. We also have a few super long forms, but these start with most fields hidden. As you work down the form the relevant lower sections are made visible.
-
I had a boss one time who personally disliked wizard type interfaces in software. He disliked them so much that he used to design screens and dialog boxes with every step of a multistep process presented all at once. That's right, every button, every textbox, every checkbox that you might encounter in a multistep process all on screen at the same time. It was extremely difficult to make this work when there were many steps in the particular screen being developed. There were just way too many different states that the screen could be in at any one time to be manageable. Have you ever had a boss who placed unrealistic constraints on your work? And what were some of those constraints?
The difficult we do right away... ...the impossible takes slightly longer.
Absolutely everyone thinks they are a UI designer. I once developed a programming language for testing and troubleshooting. (It was even a modest success, with about 1300 users). In my design, decimal numbers were represented as sequences of decimal digits, and hex numbers were a # followed by hex digits 0-9, A-F. The choice was arbitrary, but was a convention used in assemblers and had the advantage of being only one character, unlike the 0x prefix used in C. My boss, who was an electrical engineer, not a programmer, insisted that unadorned series of decimal digits should be hexadecimal, because this was the most likely use in his opinion. I argued the choice was arbitrary and users would adapt to it. I argued that users would be angry when
for i = 1 to 10did sixteen iterations. But he was the manager, and I was nobody, just a masters degree in CS and a few years experience, so I reluctantly implemented his demand. Our first user was IBM. Their number one complaint about the language was how numbers were represented. Duh! I was tasked to "fix it." Of course, adding an # to all numbers made every line longer, and lines had a limit of 255 characters, so the fix wouldn't necessarily work on all programs... Why, oh why do we hire expert language designers and UX experts, and then overrule their expert decisions?
