It's All About the Interface

I've previously mentioned the Ether-IR project I'm working on. Part of the motivation for this project is the horrible operation of our current, somewhat expensive RF (radio frequency) A/V (audio/video) remote. The remote sends an RF signal to a module inside our "entertainment closet" which then broadcasts an infrared signal to the A/V devices in the same closet. This allows us to hang the LCD TV on a wall and hide the A/V equipment away from sight, but the remote's operation is marginal at best. Sometimes, such as when our Maytag dishwasher is running, the remote doesn't work at all as it gets drowned out in RF noise emitted by the dishwasher (a quick check found that most home appliances are exempt from FCC regulations). Enter the Ether-IR, which will work over the home network, including our reliable Wi-Fi network (which is immune to dishwasher noise!). The Ether-IR will also allow us to get rid of yet another device (the remote). Our laptop, Wi-Fi enabled phone, etc., can take over the remote's functionality.

So, when I had the major functionality of my Ether-IR set up and running, I proudly showed my wife and informed her that her channel changing woes were over. I was then expecting her to jump into my arms lovingly, wooed by her 'hero engineer'. Instead, I got a "eh, I don't really like how the interface looks." I made sure to inform her the current interface was just a proof of concept, and that I would pretty it up, but the reaction seemed pretty typical based on previous projects I've worked on (she did then say the functionality was great – but, she has to). Great functionality can be meaningless without a decent interface to go along with it, and it seems that people's expectations of human-device interfaces are constantly increasing.

Eh Interface

A recent project at work involving a color display has had me doing some research on user interface design. One of my favorite Author's on the subject is Niall Murphy, who routinely writes about how to design intuitive user interfaces and gives some great examples of what not to do by reviewing some poor user interface designs. An interesting message from Niall is that, if possible, engineers should not be put in charge of designing user interfaces. Apparently, we think differently than "normal" people and tend to design interfaces BEFE (by engineers for engineers) that may not be anywhere near intuitive for the average user. We may also tend to play down the importance of a good user interface and focus more on the products functionality. As with anything, however, I think a little education can go a long way in turning engineers into good user interface designers (aren't user interface designers just another type of engineer anyways?)

As time goes on and people seem to be coming ever more conditioned to expect great interfaces such as put out by Apple and other commercial electronic companies (probably with entire user interface departments at their disposal) expectations are going beyond merely intuitive and properly functioning interfaces to include good looking, attractive interfaces. Looks don't seem to be much of a concern to Niall (just look at his website) but deserve some attention. We are all visual beings, and an attractive interface can go a long way in improving a user's experience. Even if it can't do anything to cover up a poorly designed, unintuitive interface or a product with sub-par functionality, it could easily be the deciding factor between two otherwise equal products.

So in addition to the other hats an engineer must wear, it seems like at least some study in user interface design, and maybe even in artistic design, could be very valuable. A redesign of the Ether-IR interface (with my limited web-design knowledge), as seen below, improved the interface greatly (and I am now my wife's engineering hero). It's still a work in progress, however, and if anyone has any suggestions on improving the interface, I'd love to hear them.

 Updated Interface

OpenOffice Spell Check Fail + Inventive Spelling Fail - Rant

After installing the newest version of OpenOffice, my default language (English USA) was deselected for some reason. After typing up a brief summary for a meeting and hitting the spell check button I was surprised to find that I had 0 errors! Wow, I thought, I'm really improving...

I think this was a Fail by OpenOffice on two fronts:

1. The new version should have adopted the same language as the previous version and
2. if no language is selected, spell check should report that in a message, not just proclaim no errors were found.

Luckily, I passed the paper off to a coworker for review before the meeting because while I am improving my spelling, I was lured into a false sense of confidence by the spellchecker and missed some obviously incorrect words, which brings me to the second part of my rant.

Inventive Spelling had to be one of the worst ideas ever. The theory was that it is emotionally hurtful to be wrong. So instead of "punishing" kids for spelling words wrong in elementary school, they'd just let us "invent" a spelling of our choice. This would allow us to be more creative writers who weren't shackled by our limited spelling ability. It reality, it just produced a bunch of emotionally handicapped horrible spellers conditioned to be too lazy to look in a dictionary (there was no negative consequence anyways).

Oh well, hopefully writing this blog, among other things, will allow me to reach the point where I may one day become a human spell checker!

4 States of a Push Button

The push button is commonly used in all sorts of electronic projects. One of the first lessons in interfacing a microcontroller to the outside world (after blinking an LED) is to sense a push button state. This is where the harsh realities of the analog world (as opposed to the relatively perfect digital software world) are introduced through denouncing. Jack Gansell has a classic report on debouncing that I won't attempt to add to, other than to say you should read it if you haven't already.

http://www.ganssle.com/debouncing.htm

The binary bit-shift method described in this paper offers a classic, simple and efficient way to debounce buttons and switches.

One thing I'd like to add about interfacing with buttons in general, however, is that there are actually 4 states to a button (not just pressed or not pressed).

1) Pressed Edge

2) Pressed

3) Released Edge

4) Released

I'd recommend including a state machine capable of detecting all 4 states for every project with a button, even if you don't think you need all of them up front. The logic takes very little program space, adds little in terms of processing time, and allows you to quickly add new button related functionality as the project progresses. 

You may use a push button to increase volume, for example, in which the volume is incremented by a set amount every time the button is pressed. In this case, all you want to detect is the Pressed Edge of the button. If you were to just check the button input state (0 or 1) instead of looking for the Pressed Edge, for example, a single press may lead to 25 volume increase commands depending on the length of a button press and the button input sampling rate.

Later, however, you may decide that holding the button down for more than 0.5 seconds should cause the volume to gradually increase until the button is released. If you've implemented the 4 state button interface from the start, this modification is trivial. Now you can use the Pressed Edge state to increase the volume by one increment and monitor the length of the Pressed state to allow for a gradual automatic volume increase.

Implementing all 4 states actually only requires the observation of the Pressed Edge and the Released Edge. One state after the Pressed Edge is detected the state becomes Pressed until one state after the Released Edge is detected, at which point the state becomes Released. This allows for noise (random bits) in either the Pressed or Released state to occur without screwing up the state machine.

Software button interfacing can be surprisingly complicated, but I've found this method to be very intuitive as well as a good way to future proof your code.

Open Source Ether-IR project, 1st Milestone

I'm currently working on an Open Source project that is essentially a low cost Ethernet based learning remote. The idea is to put this thing in a closet or somewhere tucked away with all your Audio/Video equipment, and allow the use of any Ethernet capable device to control your TV, DVD player, cable box, etc. I'm hoping to get a slick iPhone interface made up so you can use a Wi-Fi enabled phone as a remote. I got Microchip's Ethernet stack up and running and last night I was able to record and broadcast the volume up signal from my TV remote, so now I can crank up the volume from my laptop (at least until I power off and the memory is erased – still haven't implemented EEPROM saving yet). As the saying goes, 90% there, 90% left to go.

Full Design Gamut Position

A recent episode of the EEVBlog mentioned some new engineering graduate's frustration with real world engineering, and asked about the reality of full design gamut jobs out there. As someone who has such an engineering job at a relatively young age (still in the 2's) I thought I'd share the pros and cons to working in a small team on projects, sometimes as the sole engineer.

Design Freedom

Perhaps the biggest pro to such a position is what engineers first think of, design freedom. There is never the problem of too many chefs, or of having every design decision dictated down to you. At the end of the day I'm still a design monkey (implementing another person's idea), but being involved in the design meetings does allow me to voice my opinion about creative ideas and potential product features. When it comes to design freedom, I'd say there is nothing like doing your own thing (such as for an Open Source project), but even when designing for someone else, having so much freedom goes a long way to fulfilling the creative bug that most of us engineers have.

Bubble World

The drawback to this design freedom is the lack of fellow engineers to bounce ideas off of, discuss design philosophies with, share experience, etc. This may not be the case if you have a full gamut design position within a larger engineering company, but it seems more likely that such positions will be in small companies. Smaller companies also usually offer less in the way tools, equipment and software. This probably isn't as big a deal if you are further along in you career, but in your younger years, there may be some missed opportunities soaking up the knowledge other engineers have garnered over years of experience. The hands on experience from carrying out and testing designs, however, certainly provides for some great experience in its own right.

Paper Work

The paperwork associated with professional engineering doesn't disappear. Bills of materials, manuals, assembly drawings, final test procedures... all still need to get done. In fact, instead of escaping this type of work, there is probably an even larger burden of it that falls on the shoulders of the designer in a one man gig.

Knower of All, Master of None

Coming up with a design architecture, going through the component research, designing the analog and digital circuitry, writing the software, testing the hardware and software, etc., means it's tough if not impossible to get bored from tedious work. It's definitely an ideal position if you like a change of scenery every once in a while. This also means there is no escaping or passing off any portion of the design, even things you may not find very exciting (e.g. reading through some European Union enforced safety standard). A drawback to this is that it is more difficult to specialize in one aspect of design. When I'm working on software, for example, I find myself buying and reading software books, taking online software classes to further my knowledge, etc. When I'm working on the hardware portion of the design, I'll probably be spending more free time studying the hardware side of things. The fact is, there are probably many more jobs out there for larger corporations looking for specialized skills. If I had to find a new job, I might be competing for a firmware position with firmware gurus who spend all their time (or the majority of it) studying the software side of things, or competing for a hardware position with people who ignore software and devote their energy to becoming hardware experts. I personally tend to think that specialization is over-rated. Technologies can change so quickly that the ability to adapt and learn and utilize new technologies is more valuable than just mastering one specific skill and staying within that comfort zone, which is why this doesn't worry me much. Also, many times experience in multiple disciplines can improve your skills across those disciplines. Still, in addition to mastering the fundamentals, I think it is probably a good idea to try and specialize at least to a small degree in one general area. Most people have a preference or a particular stage of the design flow that they may find more enjoyable or interesting, and so this usually natural occurs anyway. But depending on your point of view in the specialization versus generalization debate, this is something to consider before applying for a one man gig type job.

Responsibility

Releasing a product to the world can be very rewarding. It can also be somewhat stressful. If there are any issues that sneaked through testing and start popping up in the field, there is no 'shared responsibility'. If you are the type of person who stresses easily, or who does not like having a lot of responsibility, such a position is probably not for you. I find the best way to deal with this is through extremely thorough testing. I try to switch my brain into a completely different mode in the test phase, acting as if I have no idea who the designer is, and that I don't trust him. He must have made some mistakes, and they need to be found. Slower releases, with trial runs at a customer's location with whom you have a good relationship with can be helpful here. It is also necessary to be assertive if being pushed to release the product before it is completely tested. It is better (for your reputation and the companies) to release a fully tested and verified product late than to release a faulty product early.