Building Better Software for Everyone

  • Comments posted to this topic are about the item Building Better Software for Everyone

  • I used to work for a company specialising in delivering AAA rated information websites. Accessibility wasn't difficult, it was an attention to detail thing. A lot of our work was done using CMS. We configured the CMS to pick up metadata to make sure as many of the Accessibility rules as possible were automatically adhered to.

    Screen readers can struggle with Electron apps.  Marketing people seem to hate the idea that switching colours on their website needs to be a thing. High contrast, colour blind friendly switching especially.

    The Yoast plugin on the authors page for this site rewards short sentences. This aids the cognitively impaired.

    An Accessible website is accessible by all by definition.

    Another point to note. Screen readers can be unstable and buggy.  Not sure if they are 64bit compatible either.

    I struggle with audio on videos.  Frustrated with the lack of transcripts. There's a huge body of knowledge that is inaccessible to me

  • While I agree that "Perfection can be the worst enemy of good", I've found that "Change is the worst enemy yet".  I have found that way too many people change something that works great for the end user and they end up changing the form, fit, function, or ease of use in such a way that no longer is the software (website, whatever) not only doesn't work great for the end user, but frequently doesn't even work good anymore.

    As I've often said, "Change is inevitable... change for the better is not".  Be careful what you change and make sure the reason for the destruction of some form, fit, function, or ease of use is actually worth it with the understanding that it's frequently not in the eyes of your customers.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I had a friend who was a UX specialist. He used to spend days with the real users of the system, simplifying things, getting it to the stage when it's beauty was in its simplicity.

    Then the HIPPO principle kicked in and the decree from above was "more shiny shiny". No white space was safe from meddling from above.  The attitude was "I like it then the customers will like it".  No, the customers were quite emphatic that they found shiny shiny frustrating and annoying. The pages were too busy, it was too hard to find what they were looking for. Shiny shiny always won

  • Heh... you spelled it incorrectly, David... it's not "shiny".  Replace the "n" to get the true meaning. 😀

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • The last 5 or so years I've become very interested in UI/UX. In fact I subscribe to at least two newsletters about it. What's surprised me, a great deal, is how little management (both immediate supervisors going all the way up to the C-suite) is concerned about this, in most places I've worked. At times I try to get changes made, for the users' benefit. Unfortunately that normally results in my being assigned to never design anything at all - writing code that has no UI or something similar.

    My experience has shown me that trying to make things better for the users most of the time results in resentment and sometimes retaliation. I don't do this as much anymore.

    Rod

  • Doctor Who 2 wrote:

    The last 5 or so years I've become very interested in UI/UX. In fact I subscribe to at least two newsletters about it. What's surprised me, a great deal, is how little management (both immediate supervisors going all the way up to the C-suite) is concerned about this, in most places I've worked. At times I try to get changes made, for the users' benefit. Unfortunately that normally results in my being assigned to never design anything at all - writing code that has no UI or something similar.

    My experience has shown me that trying to make things better for the users most of the time results in resentment and sometimes retaliation. I don't do this as much anymore.

    I have a good DBA friend that has a term for that... in one of our discussions, he said "Jeff... They've beat the caring out of me".  I've been on that edge before and I didn't like it at all.  I felt totally useless because they made it so and I don't like doing that kind of time.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • One thing that would be really useful would be if the top few leading screen readers could, you know, follow the available accessibility standards.

    Working on a dynamic site (that is not a CMS) it is frustrating to have to output 10 tonnes of crap for the same thing just because that bit works in screen reader A but not B, that bit works in B and not A or C. Give me strength! Why don't they just all work to the standard and if that's not good enough work together to improve the standard.

  • There's a bloody mindedness in software that is hell bent on doing things differently just on principle. Apple uses window controls on the top left, Windows on the top right. Never mind which one is correct, that is an irrelevant argument. The point is that they have chosen to introduce a point of difference that is not central to their unique selling proposition.

    That is only one example of many.  Standard marketing practice is to create the perception of significant benefit even where none really exists. It's bass ackward. Create the need rather than satisfy the existing need.

    In the disability world I'll cut them some slack because the customer base remains largely untapped and unrecognised so the drive for standardisation isn't as strong as it should be.  I saw two profoundly deaf guys using high end mobile phones. Why would deaf people need telephones? Because they struggle to communicate using speech having a screen with words expressing their questions is essential. As is voice recognition software that transcribes speech into text.

  • Some of the differences are driven by patents, which is silly. I wouldn't be surprised is there is some legal reason for the upper left/upper right. Or maybe just competition. Or fear of lawsuits.

  • There's so much in software that seems to be in the way of achieving an end goal.

    I can sit in almost any car and know that the right pedal is the accelerator, the one to the left of it is the brake, the round thing in front of me steers etc.

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply