Silly UI opinion question

[David Boyd]

I've been working on a total ground-up rewrite of a production test application that was crafted in LabVIEW 7.1 in the early-mid 2000's.  I got approval to do this since I really didn't want to glom the real required changes (mostly about hardware evolution) onto ageing software architecture, and (IMO) *way* overbusy UI.  I'm talking multiple layers of tabs-within-tabs-within-tabs.  I've worked to make a still-pretty-busy UI a lot flatter/simpler.

I'm getting tweaked in validation reviews because I declined to include an explicit "stop" button to close down the application.  (The application typically runs for multiple hours.)  No matter how I try to explain that no other desktop application has a "stop" button (I just intelligently handle shutdown via the filtered window close attempt), I'm being told, "NO, it NEEDS a STOP button".

Of course I'll give my manager what he wants, but I don't have to like it.

OK, let's hear the sage advice and similar tales come rolling in...

 

Dave

[Lipko]

I usually keep the stop button (and name it "exit" because that makes sense...).
Only because of mere laziness. But I don't really see it as a biggie... If that's the managers biggest issue, then make him that stop button and everyone wins.

I don't have many clients (they are my co-workers..), one of them interestingly claims that the GUI is too structured and wants to see all crap at the same time. Because 24" ultraHD can handle it. Um... no.

Interesting how badly designed production line application GUIs can be. So few engineers have sense for design...

Edited October 20, 2021 by Lipko

[ShaunR]

Stop isn't to close an application. It is closer to a reset.

It is to stop/terminate/curtail the currently executing task and return the application to a known state. The application is still running. The application is still initialised and the application is still in contact with devices. In desktop terms; a "Stop" is to an exit/close as an exit/close is to a reboot.

Not all applications need a Stop button (think of things like Notepad) but if you have a Start button you will probably need a Stop button.

Edited October 20, 2021 by ShaunR

[David Boyd]

And I was errant in my description above, as you've both uncovered.  On the original application, someone dropped the canonical rectangular pushbutton which comes with red "STOP" text; but they did actually change the text to "EXIT".

My original point remains, though - what other desktop (non-LabVIEW) application features a button as the way to dismiss an application?  For years I've just trapped window close attempts, and used those to start the decision process of whether it's proper/safe/etc, and handle the app exit gracefully (hardware known state, file/db management, etc).

 

Dave

[Lipko]

6 minutes ago, David Boyd said:

My original point remains, though - what other desktop (non-LabVIEW) application features a button as the way to dismiss an application?  For years I've just trapped window close attempts, and used those to start the decision process of whether it's proper/safe/etc, and handle the app exit gracefully (hardware known state, file/db management, etc).

Fullscreen applications.

[ShaunR]

Lots of applications have an exit button in toolbars. They tend to be older since menu's became the preferred way to exit as not all applications had menus in those days. But historically test and automation were full screen, single purpose applications - often with touch screens - and it's hard to click a window button if there is no window titlebar.

[Antoine Chalons]

Similarly, a few years ago, I was requested to add 2 buttons, "apply" & "cancel" before leaving a config panel.

I tried to argue that they were useless because authentication was required to access the config panel, and user who got there knew what they're doing when changing a value ; if they change and close, why would the app not keep and apply the changed settings?

It turned out users felt safer or rather "more in control" with explicit apply/cancel buttons. Meh.

Edited October 20, 2021 by Antoine Chalons

[David Boyd]

The fullscreen point I get, sort of; coupled with a touchscreen, the corner "X" may not be the easiest to access.  The target hardware will have a touchscreen monitor, although we'll undoubtedly leave them the mouse.  And while they might fullscreen the main app window, by no means do they need to.

 

For dialogs, I would generally offer a "cancel' button, and an "OK" (or "submit" or "proceed" whatever seemed appropriate labeling), and map keyboard enter and escape keys.

[Mads]

2 hours ago, Antoine Chalons said:

Similarly, a few years ago, I was requested to add 2 buttons, "apply" & "cancel" before leaving a config panel.

I tried to argue that they were useless because authentication was required to access the config panel, and user who got there knew what they're doing when changing a value ; if they change and close, why would the app not keep and apply the changed settings?

It turned out users felt safer or rather "more in control" with explicit apply/cancel buttons. Meh.

I have to agree with the requirement (although having an OK and a Cancel would suffice unless you also want to apply prior to closing the window). Stick to the norms established by the OS, familiarity is key. If I regret entering the dialog and/changing something having OK/Cancel there will allow me to recognise what to do in a fraction of a second. If this particular designer though it obvious that closing the window would revert...eh, I mean save the...hmmm. Do I need to change back the changes I did, or is it enough to close the window, I wonder....🤔

[Mads]

5 hours ago, David Boyd said:

I'm getting tweaked in validation reviews because I declined to include an explicit "stop" button to close down the application.  (The application typically runs for multiple hours.)  No matter how I try to explain that no other desktop application has a "stop" button (I just intelligently handle shutdown via the filtered window close attempt), I'm being told, "NO, it NEEDS a STOP button".

Of course I'll give my manager what he wants, but I don't have to like it.

OK, let's hear the sage advice and similar tales come rolling in..

I agree with you, and would normally stick to just a File\Exit menu option and window close. As long as extra ways of closing the application do not harm (read: confuse) more than they help I would not argue too much against them though. It depends mostly on the type of application.

Different people prefer different solutions (the true lesson in the 80/20 rule). A File>Exit (Ctrl+Q) menu option and the window close covers the standard methods, so they should always be there, but if the application might end up running on a computer with a touch screen, and access to an exit is desirable, having a button would be nice too - and not weird. (Assuming it is made distinct from other buttons that just stop sub-processes (as ShaunR mentioned earlier)).

I am lucky to normally have the final say in such matters myself😃.

PS. We used to have a financial system that did not offer any save options. Instead you were always required to select print, and then Print to file (💩!). I would love to meet and have a chat with the people who designed and approved that solution😉.  (This was even before printing to pdf e.g. became a concept, which at least makes it partially recognizable as an *optional* route today).

 

Edited October 20, 2021 by Mads

[hooovahh]

Outlook doesn't have a Stop button, so I say a LabVIEW program shouldn't need one.  Close yes, Stop no.  The only reason I can see is for touch screens that are harder to navigate.  Close can go through all the clean up stuff that it should.  The main application does also have a toolbar with File >> Exit.

In my config dialogs, I do have an Apply, Okay, and Cancel buttons and allow for a close which operates the same way as the Cancel would.  I feel like the majority of configuration dialogs I've seen behave similarly, some with only Save and Cancel.

[JKSH]

10 hours ago, David Boyd said:

I'm being told, "NO, it NEEDS a STOP button".

Can you say, "Here is the STOP button! The big red 'X' in the top-right corner of the window"? 😁

[Lipko]

4 hours ago, JKSH said:

Can you say, "Here is the STOP button! The big red 'X' in the top-right corner of the window"? 😁

I have a better suggestion. Place a full-window Stop button behind all other GUI elements, so whenever the manager accidentally clicks off an element by mistake: sadness.

[thols]

Its just ridiculous and I feel sorry for you. Is it only the manager that demands this button or are there others in the review. A requirement needs a reason to exist. If the manager anyone wants something, ask him them to make a user story of it. A Suggestion: "As a manager, I demand a stop button to close the application, because ... I'm the manager!" or "As a user of the application, I need a button named STOP to close the application, because the X is so hard to find". When you have to describe a reason for it, it will either show how ridiculous it is or a real reason for it will emerge. Anyway, you will get it documented and you can blame others for the bad design :).

[ShaunR]

1 hour ago, thols said:

A requirement needs a reason to exist.

"The software you are refactoring had one and it is too costly to change the training materials". How's that?

It is likely that a great deal of pressure had to be applied to even allow a rewrite and the manager probably had a hard time arguing for a budget to do it. Getting hot under the collar over a button isn't a hill I would die on. I would concentrate of making my life easier supporting it going forward than what it looked like-which was decided a long time ago.

Edited October 21, 2021 by ShaunR

[Antoine Chalons]

On 10/20/2021 at 10:03 PM, Mads said:

I have to agree with the requirement (although having an OK and a Cancel would suffice unless you also want to apply prior to closing the window). Stick to the norms established by the OS, familiarity is key. If I regret entering the dialog and/changing something having OK/Cancel there will allow me to recognise what to do in a fraction of a second. If this particular designer though it obvious that closing the window would revert...eh, I mean save the...hmmm. Do I need to change back the changes I did, or is it enough to close the window, I wonder....🤔

If any change was made while on the config panel, a "revert changes" button would show-up.

I admit it might not be obvious for everyone - of course what is important is : habit / expectation of the actual targeted users.