Human
Machine Interface
You may
have never heard of it, but you used them a million times by now. Although the
word "HMI" is more an industrial/PLC term for touchscreens, you could
call pretty much anything that lets you operate a machine or device, a
"HMI". The thermostat display in your living room, a packaging
machine button panel , the dashboard in your car, the control handle on fat
aunt Beth's scootmobil, et cetera.
As the
name implies, humans communicating with devices somehow. Well, I have made
quite some interfaces throughout the years. And like mode & fashion, visual
interfaces tend to change like the haircuts from Sixties Beatles to Seventies
Bee Gees, from Eighties Rick Astley to Nineties Fresh Prince of Bell air. Large
square tiles with simplistic retro symbols are hot now, but what will it be
next year? Ten years ago it was much cooler to create an dark icy, complex,
"The Matrix" style with lots of small buttons and nerd-information
scattered everywhere. When I compare my older programs with the newer ones,
they look radically different.
They all
have one thing in common though; their users have to be considered either stupid
or highly trained, and so the interface has to be as simple or powerful as
possible. And this is where our programmer brains short-circuit sometimes. You
see, making something easy difficult, is easy. Making something difficult easy,
is difficult. Read that again.
Poor Carl
When we
create a new program -let's say a packaging machine touchscreen- we programmers
have two major flaws. As we designed our own program, we know exactly how to
use it, and more important, what NOT to do. We're not able to approach our
program without pre-knowledge, with a blanco view, pressing different buttons
in the wrong order. Or worse, not pressing buttons because we have no clue what
they do, and are afraid of screwing up. If a programmer comes explaining
things, he's like "Oh that's simple. Press here, here, then here, and then
–oops.. hey, that shouldn’t be there! Weird. Little bug still in this version I
think. Well, in that case press there, and then you're done. Simple right?!!".
61 year
old Carl, who grew up in a barn without electricity, fought in the Great War,
and used the first gas-driven telephone when he was 19, nods "Yes, I
understand". But the cartoon-dream-cloud above his head says
"..........". Most people will say "yes". Because we don't want
to look stupid. But a good portion of machine operators, desktop office-clerks,
or Excel administration nannies, were never trained or interested in computers.
Listen young punks, I'm not that old, but even I didn't grew up with a
telephone and apps. It’s not a second nature.
This is what you see on the cab-display while driving in transport mode in the harvesters I program. Hate or love the colours, but the point is that a dummy can see what he needs in an eye-blink. Also, the big cartoon buttons seem friendly - you can press them without blowing up the machine or ejecting the seat.
No!
Some
people won't say "yes", and will ask though. And that's where our
second flaw comes around:
we're
arrogant. When that (ugly) lady from the office still doesn't know how to
delete an item, when the chief calls in anger that everything is stuck, or when
THAT guy complains for the seventeenth time, we're inclined to say: "Screw
them". It's their own fault. How many manuals did you write? How many times
did you say NOT to drive and press the handbrake at the same time? How many
warning stickers are there on that hot oven? From all people, why did they put
the analphabetic Indian behind the controls? Why don't they just understand?!
When
that picky ass starts telling the font-size should be 1 pixel bigger, the
button should be at the top instead of bottom, or thinks an extra confirmation
pop-up is annoying, we're inclined to say: "Really?!". What a pile of
horseshit. Pressing 1 extra little button, boohoo. LimeGreen background instead
of PastelGreen, so what? Again, we fail to see our creation from a different,
user, perspective. We make stuff, think it’s cool, and drop it off. Moving that
button to the left really isn't that much work, but it's boring work. Our mind-set
is already in that next, more interesting project. And of course, nobody really
likes it if his plans or design are questioned. Can't they just adapt and deal
with it? We're not calling Microsoft every day either, to complain about small
letters or hard-to-find settings. But we forget that, when using the same
software EVERY day, small annoyances can be become a big aversion. Do you use
programs that don't feel good, if you don't have to? Exactly.
Stay cool, have fun.
So I'm
making the Engine22 Map Editor (or “MapEd” in short) now. Or well, I've been
working on that quite some time now, but recently another guy started using it.
Julio, who contributed T22 assets since 2010, got a copy. For two reasons;
Giving a toy to play with & Feedback. There has always been a T22 editor,
but I never released it. Because I knew the interface was programmed "Rick
only". So in the past, I would typically ask an artist to make an asset,
say a Sofa. He has no clue what, where, or why, so I also give background
information. A sketch, a photo URL, or a list of requirements. He makes the
thing in Max, Blender, Maya, or whatever program, sends it to me, and then I
would import it into Tower22, using highly sophisticated (read buggy user-unfriendly)
software. And 9 out of 10 times, I would make an in-game snapshot plus a list
of improvements, and send the object back to the worktable.
It
works, and I guess big companies do it like this when outsourcing assets to
some other company that "just makes models”, without having to know what
this game is all about. But... it's not a playful, dynamic, creative flow of
course. Especially not for a creative guy that does this in his free hours. He
or she should have some artistic freedom. Fly through a room, have a careful
look, then decide "We can really use a pink sofa in this corner!". He
or she will make the asset, and import it themselves, get a preview, and tune
it until they love it. All in all, a more inviting, as well as more efficient
flow, potentially. Keep in mind that artists here work on free will. So “having
fun” is a keyword. Giving them a “fun editor” is mandatory.
A broken
editor that can’t do shit isn’t much fun though. Most artists, and certainly
the skilled ones, have been spoiled with superior tools and engines, like
Unreal, Unity or CryEngine. Of course, it’s not like mr. Rick from the
Netherlands will do a better job with two fingers in his nose in the late
hours. But I do have an advantage though. Since E22 doesn’t have to be an all-round,
multi-purpose-ultra-engine that also works on Atari and Cyborg telephone
platforms, I can narrow my set of goals. Ultimate goal? Making Tower22. Or at
least that G@#% playable demo for a start. Additional goal? Eventually letting
other (Delphi) hobbyists using the engine, or parts of, to make a somewhat similar
fashioned game.
Artists should be able to import, tune and preview their own stuff this time. Still have a LOT to do though!
Multi-useless Tool
My
experience with universal, multi-purpose software, can be described best as “Jack
of all trades, Master of none.”. And I’m not talking about game-engines, as I
honestly don’t have a lot of experience with them, but just in general.
Warehouse, administration and ERP software for example. Since every company
knows it all better, these packages are either highly complicated due all
customizable parameters (most people I know have no clue how their package
really works), or very restricted and therefore a pain in the ass. And in terms
of UI, boring. Not intuitive at all, though it’s hard to blame the makers. How the
heck should they know whether their software is being used in a paperclip
factory, Thai massage saloon, or crematoria? Different story each time. So they
have to keep it abstract and thus “bland”.
Frequent-
or pro-users deserve better:
·
Every
unnecessary step is one too many
·
Eliminate
anything that slows down the process, or confuses
·
Good
looks are nice, but speed & ease should get priority for pro-users.
·
Whereas
a non-computer audience will be better off with a very minimal, playful UI
·
Whether
you use text or symbols; be clear. Users shouldn’t have to guess what a button
does.
·
Be
consistent. Looks and procedures should be the same as much as possible.
And last
but not least, know your audience. Take their feedback or complaints serious. No
matter how stupid or picky it sounds. After all, they’re the ones stuck
with your software or device-controls the whole day long. But! With one big
side-note: have a vision and lead. You can ask a person what he wants, and implement it exactly
that way. But if you ask another person, you’ll get a different story again.
And what do you get if you mix 10 different colours? Yep, brown mustard poop.
You should decide the main direction, whether to goo blue or pink. Then use the
feedback and comments to fine-tune.
Engine22 Map Editor improvements
Now the
Engine22 Map Editor. The audience is experienced here, they know how to turn on
a computer. That means less concerns about stupidity, but at the other hand a
more critical audience, as they know similar software as well. My first mistake
was that the initial design had pretty large buttons with icons. The stuff I’m
used to when making agricultural machine-cab interfaces. While driving you don’t
want to read small letters (some can’t even read). Big simple dumbass
indicators is what we needed there. But for a modelling/rendering application,
big dumbass buttons will consume a lot of precious space. Turned out my “test
guy” didn’t have a very high resolution either, so an awful amount of space was
wasted on funky symbols, thick Form headers, and voids. Meaningless stuff.
So I
received a whole list of suggestions to “compress”. Got rid of the standard
Windows form headers, gone with the big symbol buttons, increase density, move
less important functions into a sub-menu or something. Second, a lot of hotkeys
had to be added. Yes, moving the mouse from A to B to click, takes a second
(and a nano-calory) more than having your other hand pressing the magical
combination. Personally I’m not a hotkey guy, as I can’t remember them. Kids
still showing me handy shortcuts that have been in Windows for ages J But again, if you had to use this
tool a substantial amount of time, anything that adds up to the comfort, should
be embraced.
Lots of panels while editing this sofa. But, in contrary to the previous version, you can now move and hide all panels quickly, with shortcut keys eventually.
Third,
and probably most important, it must work. That’s captain obvious, but really. Sometimes
it’s better to keep half-finished stuff hidden, instead of implying that featureX
is operational while it isn’t. A program like MapEd is complex. It has dozens
of features. It’s more or less the game + an editor, double trouble! Since the
engine core itself is under heavy construction as well, it sometimes feel likes
a Jenga tower. Insert a block here, and crap, some other part falls out.
Julio
began his journey with importing stuff (OBJ files and textures) to make them “props”.
And as Murphy tells, more than a handful of things crashed. Of course there was
the usual video-card beef. Shader bug here, OpenGL not supporting that, his
screen blurry while my isn’t, et cetera. As expected. But also some of the
executables didn’t run due some missing library for 32-bits, and it seems every
3D package does a different job exporting OBJ files, as that didn’t work in one
shot either. Polygons messed up, textures upside down, that kinda stuff.
Since
Julio is my test-guy, there is room for error in this stadium. But at some
point, he will also be an end-user. So be careful with that “room for error”.
If something crashed the first 100 times, that fragile feel will haunt your product
for the rest of its life, even if the bug has been dealt with. Every update
should feel as an improvement, not a wild trail-and-error ride. So I try to
avoid a billion updates, and to make things more comfortable, E22 has a tool
called “HUB”. This tool checks a FTP server for engine and asset updates. Especially
the latter is interesting. When you’re done with an object, material or room,
you can upload it within a few clicks. Then other users download it next time
they check for updates. Too bad HUB itself still has a couple of issues :p
