Press my Button

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