Jump to content

Silly UI opinion question


Recommended Posts

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

Link to comment

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 by Lipko
Link to comment

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 by ShaunR
  • Like 1
Link to comment

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

Link to comment
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.

Link to comment

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.

Link to comment

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 by Antoine Chalons
Link to comment

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.

Link to comment
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....🤔

Link to comment
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 by Mads
Link to comment

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.

Link to comment
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"? 😁

Link to comment
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.

Link to comment

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 :).

Link to comment
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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.