Saturday, September 17, 2016

Annoying Habits of Computer Science/Software Engineering (Students) Designing UI's...

Over the past few years, I've had the opportunity to have a front-seat view of how groups of 3rd year computer science/software engineering students approach the problem of designing a UI. It has been said in a few places (citation needed) that ultimately, the way group projects end up taking place for class projects and in real life are largely similar(ly awful). Thus, given that many of these folk will end up in the workforce in the next few months to a year's time as the newest batch of "professionals", if what I've seen is anything to go by, no wonder we're kindof perpetually doomed...

It's also no wonder then that we're often burdened with so many absolutely terrible systems for what-should-be-mundane/trouble-free processes like activating cards or making use of various services for the first time, etc. Or, nastier problems like the current religious dogma + regime of "automatic software updates" that regularly foist themselves at you every other day, usually at the least convenient times, and from time to time leaving a colossal mess behind when they're done.

In particular, there are recurring issues that crop up time and time again, and affect almost all the students:
  1) The application in question "must" have a fully-fledged Login + User Account system, complete with all the username, password, and associated paraphernalia. Aaaaaaarrrggggh!!! Never mind if the thing will only ever be used by a very very small number of people whose identity is already known/easy to verify (if it's even necessary to do so in the first place, which in most of the cases I've seen is not the case!), or if the thing may only end up being used once or twice in a kind of "throwaway" transaction!  Apparently the best way to show off your UI design chops is to offer your own take on the famous old hazing ritual as "everyone else is doing it"...     [NOT!]

  2) Given the freedom to choose what their project will be, 90% will choose to work on a system that is either a social network, or is thinly veiled excuse to effectively create another f***ing social network (*A). But, even without this freedom, it's still only a matter of time before some will come to the conclusion that there "needs" to be dedicated social network-esque functionality built into there somewhere...  Cue the need for all the things in #1, including ze "friend list" and some "star rating" system.

  3) A failure to fully appreciate the consequences of "context" - in particular, the issue of operating environment (when, where, challenges/competing demands/restrictions+limitations, workloads, ergonomics), and "not thinking beyond the screen". This often stems from not stopping to first assess/clarify/define your own assumptions before leaping into action. Examples abound here, from considering the practicality of being able to read/press tiny on-screen buttons on a GPS/In-Car system on the road, to the practicalities of standing in front of a fridge to manually input data about what groceries you'd just put in (or to do other stuff like that), or the practicalities of having to yank out your phone and swipe away the lock screen everytime you just want to turn the lights on when both hands are fully carrying several heavy bags each.


The first two are "annoying" issues (*B) - if this is all that most of the people with the skills to build stuff can come up with, then humanity has a problem. No wonder we're constantly faced with such a barrage of terrible inane "me too" crap. Gah!  Where are the people who want to give some actually "meaty" problems a look for a change (e.g. things like improving the input interfaces for various creation tools, and stuff like that)?!   As it stands, I've come to understand that for a lot of people, this lack of flexible/creative/innovative thinking is pretty much beyond them, and that there isn't really anything that can be done about that... they're pretty much fixed in stone like that.... :/

The issue about not fully appreciating context is however something that we can hopefully make some progress on. Indeed, I've come to realise that this may be one of the key takeaways from a course in HCI (just like lessons about affordance, mental models, and the limits of human capabilities). That is, you cannot really do a good job unless get out of the mindset that you're dealing with visuals on a fixed-position screen that's optimally placed, and is interacted with in an nominally "optimal" way in a calm environment (i.e. no stress, no physical challenges/distractions, no time pressure/constraints, no loud background noises, and the user is sitting/standing in front of the screen without the whole world around them moving around/vibrating or anything else). Life is messy. Humans are messier. Rinse. Repeat. Absorb. Let it soak in. Keep absorbing.... TBH, in a way, this is one of the hardest lessons to learn, and does take quite a while to really truly deeply grok it, but it is also absolutely critical for anyone who works on anything human-facing.

I also mentioned the issue of "not thinking beyond the screen". Perhaps it's the fault of most people's worldview being that "interacting with a device = poking it with a single pointing point" (e.g. the LMB of a mouse, or directly using a finger on a touchscreen), and/or also that they are being asked to create an "interface design" in a course of "Human Computer Interaction". Certainly, the prevalence of touchscreen devices these days has but solidified this view. So, a lot of the time, there is this notion that "if we're not making buttons to do this, we haven't designed any interface". I've heard quite a few variants of this over the years. But to not think beyond tiny glowing rectangles and poking fingers, is to ignore the fact that most (able-bodied) humans are more than just giant eyeballs with a single poky-thingy sticking out of them.... instead, we have a wide variety of limbs (remember, we have 10 whole fingers on two separately articulated arms) that have a wide range of movement that can be put to use, as well as other senses including a highly-refined sense of touch and hearing. Convincing them however that there is value in "No UI" (i.e. the idea that the less "manual button mashing" needed by the user to communicate with the machines), and that things that aren't part of a screen layout are still part of the overall "interface" between humans and computers proves to be a much more challenging task.

Finally, there is the issue of not clarifying/understanding your own assumptions and biases upfront, and making sure that everyone is on the same page about these things. Again, this is one of those things that isn't really obvious to a lot of people, and is a lesson that not many learn, as it's again one of those things that's hard to get a good handle on. However, from a "been there, done that" POV, I've learned over the years that this is one of the best things you can do to really start deeply understanding your problem space, and can also help you a lot when you start getting stuck and "cannot think of any ideas". As an old Chinese saying goes, "take a step back, the ocean is wide(r), the sky is tall(er)". When you get stuck on a tricky/intractable problem, perhaps one that's been driving you in circles for a while, I've learned that one of the best things you can do is to stop and ask yourself again about all the assumptions you're making about the situation. For instance,
      - Does it really have to work this way?
      - Is that really the case?
      - Do we really want to be doing that?
      - Are there any other alternatives? What about if we removed that/those restrictions we'd earlier set?
      - What rules/beliefs about the situation do I have?  Be honest.... I really do mean all of them (even the ones you still think of as being kindof inconsequential)...

If you fully flesh out and get to grips with the assumptions you've been working under, at some point, you should eventually start seeing some things which don't quite stack up. Or maybe, to get things moving, just try relaxing some of those assumptions and see whether doing so gets you unstuck. For example, to use the previous example, thinking of your interface as being more than just what is shown + "clickable" on a screen is an example of challenging an assumption you've probably been unconsciously using to limit your idea space...


(* A)  - The most popular projects in general are:
             1) Recipe/What-should-I-eat-tonight App    (which is also the prime candidate for social-network-ifcation)
             2) Pizza Ordering App
             3) Trip Planner Tool   (mainly the itinerary/booking selection part)
             4) "Smart Fridge"
             5) "Smart Car" Stuff - GPS/Infosystem/Controls/etc.
             4) Ride Sharing App
             5) Student Planner App  (basically a glorified timetable/appointment-calendar/notifications tool)

The most interesting project I came across was one where they wanted to design an educational math game - the usual "defeating monsters" type of deal. Their initial prototypes were quite "rough" (as in, they were using some general repurposed art, which made it impossible to figure out what was going on, and/or how that related to what they said they were working on). Eventually though, after some "corrective interventions" they managed to pull through, overhauling their work to better communicate their design (and often in some rather creative and nice looking ways). So, overall, I think this one turned out quite well.

(* B)  - Let it be known that if I had to grade such projects at some point (and had freedom/authority to decide the marking scheme), that I would have at least some "penalty points" for "heavy handed/superfluous login + user account systems". Extra points (or perhaps, an equivalent proportion of the overall grade, if I'm feeling particularly annoyed) get taken off if a large proportion of their report/design docs are dedicated to dealing with this crap... Change has got to start from somewhere, and I believe that in the majority of cases, such systems get in the way far too much. No, your app/service/tool does NOT need its users to create yet another username+password combo that they're likely to forget/etc. anyway...

No comments:

Post a Comment