Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Monday December 17 2018, @11:17PM   Printer-friendly
from the I-don't-see-what-you-did-there dept.

PLEX, this last week pushed out changes to its ROKU users (I am one). That made using PLEX nearly impossible for some people. Light and Dark gray color palate. White text on light gray background, to the point of the PLEX 1/4 screen height logo and spinning-working throbber being lost on the background.

So war ensues... See Plex.tv support forums if you must.

My question to you all, "What is TECH's responsibility to the Handicapped?".

Should good TECH also have a backdoor method allowing those with usability issues to still use the product, when TECH changes directions? What about lifetime pre-paid services that are now unusable? Should there be immediate return of funds, so we can buy the second best solution (now the best choice for us)? Should any change be signed off by a third party auditor to insure continued usability?

So again, asked differently, what is TECH's moral responsibility?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Insightful) by black6host on Monday December 17 2018, @11:21PM (10 children)

    by black6host (3827) on Monday December 17 2018, @11:21PM (#775615) Journal

    I've long said that you never remove functionality from your software, especially if it's commercial. You never know how people are using it. I know this from both a developer and end user point of view. I think it's ok to move some features that are not used much but be prepared to educate your users either by good documentation , or via support channels. IMO, this includes the user interface.

    Starting Score:    1  point
    Moderation   +3  
       Insightful=2, Underrated=1, Total=3
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 5, Insightful) by fyngyrz on Tuesday December 18 2018, @02:25AM (8 children)

    by fyngyrz (6567) on Tuesday December 18 2018, @02:25AM (#775693) Journal

    I think it's ok to move some features that are not used much

    One of the earliest (and excellent) rules of GUI design was to not move things around on your users. They develop habits based upon the functionality they use, and moving stuff around, either contextually or from version to version, is a bad idea, as it prevents those habits from forming (or ends up having the user do the wrong things.) The guideline was for controls that were not presently relevant to become disabled rather than move around or disappear entirely.

    For an example of the former, in GMail, when you don't have an email in the list selected, the toolbar is...

    [ ] Refresh More

    ...but when you have selected one or more emails, the toolbar begins...

    [ ] Archive Spam Delete

    ...and yet again, if you're working in a label-based "mailbox-ish" thing, the toolbar begins...

    [ ] Remove_Label Spam Delete

    The consequence of this, and other context-based changes of this toolbar, is that your use of GMail features here must be considerably more mindful than they would need to be if the GUI wasn't unstable. That means past a particular point, the user can never get used to the interface, as what the interface is is constantly altering. You get to spend (I would argue, waste) your mental horsepower on the GUI instead of whatever it is you're trying to work with.

    In the GMail example, a habitual click on the first toolbar element, intending to archive an item, ends up removing it from the mailbox (Remove_Label) in the context of a mailbox because the button has completely changed roles. Then you have to go find it, put it back, etc.

    For an example of version-to-version disruption, I'll just point at Photoshop, which has utterly confused its users time and time gain to such a degree that it is mind-boggling.

    The key to not doing this in application design is planning ahead so that if/when "more" becomes necessary, you have an intuitive, reasonable and non-disruptive place to put it. This, in turn, requires careful thinking about the classes of things your application does, and might do in the future when you design the GUI in the first place.

    This isn't just an IMHO of mine. These are ideas that were codified as far back as the 1980's, when GUIs began to pop up in many venues within a fairly short span of time. I've never run into a good argument for making GUIs change in the intervening years. The most common one is "but the new!" to which I refer straight back to "but plan your application."

    The only time it is reasonable to move things around is when you know, right up front, that there will be so many things that there must be a great deal of room for them; in that case, putting them in their own region where they do not disrupt the rest of the GUI is the way to go. Letting users build their own stable toolbox/caddy is also very helpful to them.

    For instance, in one graphics applications I wrote which had really ridiculous numbers of things it could do, I did both: set it up so that users could create a tool caddy of their favorite tools, and made sure that when tools various were in scope, the controls and options did not disrupt the rest of the GUI. This was (waves hands vaguely) a Photoshop-class application; extensive image and image sequence manipulation. So it can certainly be done. Planning. That's the key.

    Yes, sometimes things have to change. No, it shouldn't happen often, and it really shouldn't happen to the main GUI during the course of one invocation of an application unless you've completely changed what you're intending to do.

    --
    Yes sir, two copies of "Math For Dummies" at $16.95.
    That'll be $50.00

    • (Score: 5, Funny) by driverless on Tuesday December 18 2018, @02:31AM (1 child)

      by driverless (4770) on Tuesday December 18 2018, @02:31AM (#775699)

      For an example of version-to-version disruption, I'll just point at Photoshop, which has utterly confused its users time and time gain to such a degree that it is mind-boggling.

      Gmail isn't much better. Every time they advertise a UI refresh I know I'm going to get calls from all sorts of relatives and neighbours who will be kicked back to day 0 of using Gmail just because some latte-sipping hipster cretin at Google has decided they need to rearrange the UI deckchairs yet again.

      • (Score: 4, Funny) by fyngyrz on Tuesday December 18 2018, @01:32PM

        by fyngyrz (6567) on Tuesday December 18 2018, @01:32PM (#775810) Journal

        ...just because some latte-sipping hipster cretin at Google has decided they need to rearrange the UI deckchairs yet again.

        You, sir or madame, win the "awesome phrase of the day" contest. 😊

        --
        I think I'll slip into something more comfortable.
        Like a coma.

    • (Score: 0) by Anonymous Coward on Tuesday December 18 2018, @06:26PM (1 child)

      by Anonymous Coward on Tuesday December 18 2018, @06:26PM (#775951)

      Overall a nice posting, and I like your use of abbr tags, but...

      This isn't just an IMHO of mine.

      IMHO was "In My Humble Opinion," not "honest". So now you know.

      Ehh, maybe I should just let you kids stomp over my lawn.

      • (Score: 2) by fyngyrz on Tuesday December 18 2018, @09:49PM

        by fyngyrz (6567) on Tuesday December 18 2018, @09:49PM (#776064) Journal

        I've always heard it the other way. I've added that to the IMHO definition. Thanks!

        --
        I may be apathetic, but I don't care.

    • (Score: 2) by urza9814 on Wednesday December 19 2018, @04:58PM (3 children)

      by urza9814 (3954) on Wednesday December 19 2018, @04:58PM (#776378) Journal

      I think it's also a matter of how well you understand the software in question, which fits the topic of TFA pretty well too.

      If you generally know how email works, and what Gmail reasonably can and cannot do, then swapping out those options in that way makes perfect sense. If I select a single mail, I might want a reply button. If I select five emails, I almost certainly don't, because that doesn't make much sense. (In theory you could make it work, but I don't know any mail client that would allow bulk replies like that.) I don't want a massive toolbar full of options that I can't use; just show me what is relevant to what I've already done. However...I can also see that someone like my father wouldn't know anything about that, and it's entirely possible he might decide one day that he needs to send the same reply to three people, and get really frustrated when he can't find the reply button after selecting those mails.

      Ultimately that's the same disconnect that causes problem for those with disabilities. The people who design software will design something that makes sense to them, with all of their knowledge about the inner workings of that software and all of their experience/frustrations/appreciation for other software that they're familiar with.

      This, I think, presents diversity (ACTUAL diversity, not the "clones of different colors" diversity which many organizations practice these days) as a kind of corollary to the practice of "dogfooding". It definitely helps to find and fix both bugs and just plain annoying behavior if the people writing the code have to use that same software every single day...but the more homogeneous the workforce, the less effective that will be.

      • (Score: 2) by fyngyrz on Wednesday December 19 2018, @06:49PM (2 children)

        by fyngyrz (6567) on Wednesday December 19 2018, @06:49PM (#776428) Journal

        I think it's also a matter of how well you understand the software in question

        The point I was making is that software that makes you spend more effort than you need to in order to understand it or even access it is poorly designed. And software that makes you re-evaluate and/or re-locate the available options every time they are presented is exactly that.

        I might want a reply button. If I select five emails, I almost certainly don't, because that doesn't make much sense.

        Then it should be disabled. Not missing.

        I don't want a massive toolbar full of options that I can't use; just show me what is relevant to what I've already done.

        Disable/enable clearly indicates what is relevant if you're actually looking for something specific, and doesn't require re-evaluation of interface activity. What you need to use is always where you expect it to be, so it's much easier to access, even for beginners and disabled users, but also for fully abled, experienced users. That's ideal.

        What an unstable interface does is forces your mind to work on things it doesn't need to work on. While you may indeed be comfortable with that, it's not the best way for a GUI to operate, and it inconveniences the heck out of new users, casual users, visually impaired users, etc.

        As long as point-n-click or any other visual-to-physical mapping mechanism is the interface paradigm, stability is better than instability. For example, with applications that transition to voice interfaces, this will no longer be an issue. But as of now, we're still stuck with locating things at/on screens for anything of any real sophistication.

        --
        Hypocrisy is the Vaseline of political intercourse.

        • (Score: 2) by urza9814 on Wednesday December 19 2018, @08:14PM (1 child)

          by urza9814 (3954) on Wednesday December 19 2018, @08:14PM (#776495) Journal

          The point I was making is that software that makes you spend more effort than you need to in order to understand it or even access it is poorly designed. And software that makes you re-evaluate and/or re-locate the available options every time they are presented is exactly that.

          Sure. But how do we define "more effort than you need"? Learning Emacs requires a TON of effort, but plenty of users would attest that it's well worth the effort for the efficiency it gives you. Software that tries to be too smart and do too much for you is damn annoying, because it's always getting in your way and making you revert its changes (Microsoft Office is an excellent example...). Software that does too little automatically is ALSO a pain in the ass though. If 'mount' can tell just by looking at the filesystem what type it is, then there's no reason for it to force me to specify that option.

          I never had to re-evaluate or re-location options back when I was using Gmail. I knew what I was trying to do, and I knew what sequence of actions I needed to take, and I knew where the right buttons were going to appear. No problem. And hell, if I wanted to move those buttons around, I knew how to do that too.

          Disable/enable clearly indicates what is relevant if you're actually looking for something specific, and doesn't require re-evaluation of interface activity. What you need to use is always where you expect it to be, so it's much easier to access, even for beginners and disabled users, but also for fully abled, experienced users. That's ideal.

          There's a limit to the screen space available. I don't want to be losing room for content so that I can stare at a big list of buttons that are irrelevant and unusable. Although I think an ideal system would probably use both -- a toolbar that changes depending on what content is active, and a full menu system which does not. I don't want to have to click through a bunch of menus just to find the 'reply' button, but a decent piece of software is probably going to have too many options to have them all just one click away at all times. Let those menus be user-configurable too though, because not everybody is going to be using the same functions all the time.

          What an unstable interface does is forces your mind to work on things it doesn't need to work on. While you may indeed be comfortable with that, it's not the best way for a GUI to operate, and it inconveniences the heck out of new users, casual users, visually impaired users, etc.

          I think you're mixing up different usages of "stable". An interface can change depending on your actions while still being stable. They certainly shouldn't just randomly move buttons around in the next version -- if it gives me "Reply | Reply All | Forward | Delete" when I open a message, it should give me the same list of options when I open a message in the next version, and it certainly shouldn't do something like swapping the locations of Reply and Delete. But it doesn't have to show me the same exact options when I'm reading a message vs when I'm looking at my inbox, for the same reason that the answering service at the local public library has a different set of options than the answering service for my doctors office. Context is important, and giving different options in a different context is not a problem, it's a typical expectation.

          Flooding your users with unusable and irrelevant information is almost as bad as giving them no information at all.

          • (Score: 2) by fyngyrz on Thursday December 20 2018, @01:31AM

            by fyngyrz (6567) on Thursday December 20 2018, @01:31AM (#776620) Journal

            But how do we define "more effort than you need"?

            Easily: effort that you spend on a task that gains you nothing. Like re-reading the toolbar to see what buttons are there now, and where you have to go to get at it, as opposed to the last time you looked at it. It's useless even for the abled, and for the disabled, it's tedious and a significant roadblock. New users have to read no matter what. Users with some time under their belts will internalize the positions and the functionality and their efficiency will significantly increase if the GUI is stable. If it is unstable, they either can't do that, or it will take a lot longer, and in addition, a risk factor of a button in a particular place doing something unintended now exists. Positions map to functionality with software users, and such mapping increases their efficiency. Unless it isn't there, in which case they have a steeper hill to climb.

            I never had to re-evaluate or re-location options back when I was using Gmail.

            No, you had most likely just internalized the relearning you'd done, and were able to use that because you have, or had, good vision and motor skills. Or you were reading them — every time. I absolutely guarantee you that if you'd simply read those buttons once and then never again, you'd be right in here complaining about how you unintentionally had done this or that, and would be able to trace the cause directly to the fact that the buttons and their associated functionality physically move around. I also guarantee you that if you were significantly impaired, that relearning would have been a process that involved many invective-laced sessions.

            There's a limit to the screen space available.

            Already addressed in my first post in the thread.

            I don't want to be losing room for content so that I can stare at a big list of buttons that are irrelevant and unusable.

            At most, this argues for a user-selectable, optional unstable mode vs. a default stable mode. In this particular case (GMail), it doesn't — because the menu is quite sparse. However, you don't have to read the disabled buttons. In a good UI, the fact that they are unavailable at the moment is very clearly indicated in a way that obviates having to read them at all. The ones that are operative at any moment will stand out visually — and they'll be right where they always are. If you're actually reading, you'll see them easily without having to read anything but them, and if you're using motor memory, it'll just work.

            I think you're mixing up different usages of "stable".

            I think I've been reasonably clear about how I've been employing the term here, but I will provide a specific definition for your benefit:

            • Buttons that move, change function and/or outright disappear are unstable GUI elements.
            • Buttons that remain where they always were, don't change function, enable/disable based on availability, and don't disappear are stable GUI elements.

            These concepts apply without confusion in the context of a single session, in the context of multiple sessions, and in the context of version-to-version changes/updates.

            Flooding your users with unusable and irrelevant information is almost as bad as giving them no information at all.

            You're shooting your argument in the foot here. You've said that you know where things are regardless of the instability, but you're also saying that you can't learn where things are when they don't move. It's either one or the other — because in either case, you have to learn every button you use. In the stable case, you learn them and they don't move. If your argument focuses on how much you have to read, then you actually don't know where the buttons are anyway, so you have not learned where things are, and you're not seeing the forest for the trees. Also, a disabled button should be very clearly indicated as disabled. No need to read it, it's dimmed, you can't use it anyway. Zip, on to the next button, presuming you're still reading them (inexperienced user syndrome.)

            There are no fewer active buttons in a stable interface; the things you can use remain right where you expect them to be, every time. Whereas in order to learn to use them in an unstable interface, you have to learn what they do and learn where they are and when you should click here or there, or, you have to reread them every time to see what your options are. The learning load is higher for the unstable case than it is for the stable case, every time, and it persists much longer.

            For example (applies directly to GMail, as it happens):

            Unstable way: Delete is in 2nd position. Or first, if (condition obtains.) Results hitting 2nd button vary. They may cause harm or at the very least, a lot of extra effort. You can't have a habit tied to hitting the second button, because it will (not may, but will) bite you. You must either read/interpret the buttons every time (text vs. icon) or learn how the interface mutates through its various unstable modes.

            Stable way: Delete is in 2nd position. Results hitting second button will ALWAYS delete, unless button is disabled, in which case, no harm done (but it's right where it always should be, so habit of hitting second button is tied — in a stable manner — to actually deleting things.)

            Flooding your users with unusable and irrelevant information is almost as bad as giving them no information at all.

            Right. And an interface that mutates shovels extra information at them every time it mutates which increases the cognitive (and physical, and time, when we're talking about the disabled) load on the user. So you really shouldn't do it unless you are absolutely forced to (and again, I've already addressed that point.) Again, disable the button properly and the user will ignore it. No extra- or re-learning required.

            The last word is yours. I have made my points repeatedly, and am satisfied that I have been clear enough.

            --
            All those moments will be lost in time, like tears in rain.

  • (Score: 5, Funny) by driverless on Tuesday December 18 2018, @02:27AM

    by driverless (4770) on Tuesday December 18 2018, @02:27AM (#775696)

    My question to you all, "What is TECH's responsibility to the Handicapped?".

    Don't we already provide a GUI for the handicapped who can't figure out how to use a CLI? That's already a pretty big concession.