Embedded - 165: When People See a Button

Episode Date: August 16, 2016

Shimona Carvalho (@shimonkey) joins us to talk about user interface design in embedded systems. Then we talk about internationalization and localization. Then photography. Shimona's website is shimonacarvalho.com and her Flicker account is shimonkey. For an introduction to user interface design, Shimona recommended The Design of Everyday Things by Don Norman. Internationalization and localization were delved in far deeper in episode 26: The Tofu Problem. Some of the material from that will be on the embedded.fm/blog this week. We mentioned an auxiliary, secret RSS feed that goes all the way back to episode one. (Some notes haven't been filled in yet). We're also on Youtube now.

Welcome to Embedded. I'm Elysia White. Happy to be here with Christopher White. Shimona Carvalho will be joining us today to talk about user interface considerations in embedded systems. Speaking of users, well, listeners, we recently got some criticism of an unusual sort.

Guillermo Amaral emailed us to say he enjoys the show, but now his kid hates riding in the car with him. As he turned on our show recently, she said, computer NPR again? Well, Scarlette, Amaral, I'm sorry you don't like us, but with criticisms like that, we sure like you. Hi, Shimona. Thanks for joining us today. Hi, Chris. Hi, Alicia. Pretend I've never met you before. Thanks for inviting me. Well, Shimona's not actually related to you, so...

What? Shimona, could you tell us about yourself? Yes. I am a firmware engineer that specializes in UI, and I work for Fitbit right now. Been there for about three and a half years, so worked on Surge, Blaze, Alta, and future things. Previously to Fitbit, I worked for Texas Instruments and Qualcomm, so very much more chip-based products, not consumer electronics. Excellent. Okay. Well, now we're going to try the lightning round where we ask you short questions. And maybe we won't ask you for follow-ups if we're behaving ourselves, but maybe we will. We'll see. Chris, do you want to start? Sure. Beach or mountains?

Oh, let's see. I used to be beach because I lived in Southern California, but I'm starting to appreciate the mountains up here in Northern California because they're definitely beautiful and forest filled. That's very diplomatic. How about IAR or Code Composer? Oh, both are terrible. I have to say, I mean, maybe this is just because I have some distance from it, but I feel like Code Composer by the end was better. But I haven't used it, to be honest, in five years or so.

Least favorite planet? Maybe Jupiter. It's so big, but so useless. No chance of life. I don't like it. That may be my new favorite question. Tabs or spaces? Spaces.

How many spaces are in a tab? Two right now. Is that going to change? Do I need to be warned? Well, I have different projects. Some of them have four. Some have two. I had a question.

It was in my head. Where did it go? C or C++? C. Definitely C. Favorite subatomic particle? I'm going to go with electron. Chris probably knows why. Science, technology, engineering, or math? I think engineering.

And I think of engineering as solving problems. And I think that I'm more into solving the problem than just doing math for the sake of math or science for the sake of science. Evil science for the sake of evil science is okay. Exactly. Donuts or bagels? Donuts. I like sweet stuff. Not a big bread person with all the sugar.

Is a cell phone an embedded system? You know, I worked on cell phone chips for like a decade before this, and they used to be embedded systems. But now, more and more, you know, they're really not. They're generalized computers. So I kind of feel like they're turning into non-embedded systems. Follow-up question. Is a smartwatch an embedded system? Same thing. So now I think smartwatches today are like the cell phones of a decade ago. They're still, you know, starting out to be fairly limited in function and specific in function. But 10 years from now, maybe five years from now, they're just going to be little tinier,

even tinier computers. What's the worst formal version control system you've ever used? Maybe Perforce. Oh, God. Oh, yeah. Yeah. maybe perforce oh god oh yeah yeah i feel like that that's kind of a the existence of perforce makes it so that people can't answer that question rationally and say git yeah i know i think i mean and i think to be honest i never ever managed to completely

understand perforce so that that's a big part of it. And git is equally hard to understand, but I've gotten a little bit closer, I think, to feeling comfortable. Gryffindor or Hufflepuff? Oh, I don't even remember which one's which. I just know the evil one is Slytherin, so not Slytherin. So I don't know between those two, though. What science fiction technology or concept do you think will be real in our lifetime? I think, like, the Minority Report, like, and I think they had it in Avatar as well. Like, the holographic screens that are floating around, and you can just move things from your computer to the sky. And I don't know if this

is going to happen through actually having, you know, something in the environment that projects it or whether we'll be wearing augmented VR type glasses that makes us feel like we're interacting with screens everywhere. But I kind of think that we're pretty close to that, and it could be kind of cool to have that. I already feel my arms getting tired. Yes, I know. That's the one problem with that. But we don't have to necessarily have the interface all be in the hologram. We could be using interfaces on a surface.

Okay, that does bring into the user interface aspect of this, which I don't know that we can talk about user interfaces before we really define what space we're talking about because that sort of thing where you throw screens around, that is a user interface, of course, but embedded systems are different. So what do you think of as an embedded system? You had good answers for the phone question, but how do you define it? I think, and this, yeah, this is a tough one, I think.

I think of it as a system where there's a specific function. It's not a generalized computer that's going to run a wide varietywatches, is that when something becomes very useful and ubiquitous, we start piling on all sorts of functions and jobs onto the same device. And then very soon what you have is a small computer. And then on the other hand, I think that the skills that we learn as embedded engineers, I mean, we still can use them on smartphones and smartwatches. So there's still that aspect of it. But obviously, there's a difference between, you know, writing the driver for the touchscreen on a smartphone and writing an app that sits above an operating system that gives you a lot of flexibility. Okay, so what do embedded software and hardware engineers need to know about user interfaces? Well, for one, that they should care. I think that, you know, when I say I'm into embedded and UI, I get a lot of what, how can you be into both?

Like they're mutually exclusive or something. And they're really not because I think embedded engineers need to care even more about user interface because we can't just fall back to, you know, you can't assume your user has a keyboard and a screen and the usual things that if you're writing software for a computer, you can fall back to the most obvious user interface. You don't even have to get clever about it. But with embedded, everything's a challenge. What do you do with just one button? And what do you do? How do you hook up, say, Wi-Fi if your user has one button on their device? How do they put in a password?

You need to really think through all these things or your device is going to be really unusable. And the other thing is a lot of embedded is in devices that, you know, we're not sitting and paying attention to 100%, like in your car or something, all the electronics in there, which are, you know, definitely a kind of embedded system. You have to be able to operate them while you're driving and not spending all your time looking at the screen. And it's very easy to make it tough enough or complicated enough that you start taking attention away from driving so i think our our interfaces may not be the traditional interfaces but as a result they need to be thought through a lot more before we design them do you have an example of a good user interface?

Yeah, I mean, there's a lot of them. I mean, I think that we don't notice them when they're good. I mean, a lot of like car stereos that are not like the latest kind with the touch buttons, I can operate my car stereo without ever looking at it and that's awesome like I don't need to look at it it does what I need it to do I can change stations I can set new stations and there's a lot of pieces of software where doing the exact same thing takes a lot more attention and care and then I have I have a lot of cameras and so cameras some of them have really good interfaces. You can learn them to the point where you don't have to look at anything,

and you can change five settings in the span of like three seconds and take your photo. And there are other cameras where you realize, oh my God, I can never get to the setting without fiddling for like five minutes. A lot of that comes down to having physical controls that are sufficient to map to enough functions. You mentioned the single button, how do we do Wi-Fi kind of thing, which is one extreme.

And I think a lot of the car stereo example and the camera examples, for me, when those things work best is when there are physical controls that you can, without looking, you know what this button does or you can map it to do something. It seems like we're moving away from that and moving to touchscreens, which are inherently, there's no feedback. You can't blindly use a touchscreen.

So it seems like there's a challenge there now. Right. And I think it's actually, it's actually terrible when you have a touchscreen as your stereo in the car, and there's no way to use it without looking at it. I'm really hoping we move very quickly to some sort of system that is a little more usable than that. I know it's fun to put a touchscreen everywhere, but we're going to crash some cars before we learn learn something there well the touch screens you were talking about keyboards and screens and I was thinking that one of the differences between a generalized computer and embedded system is whether or not there's easy help I mean on my computer if I something, I just find the help button or on my iPad, there's always help around. But when I look at a Fitbit or a car stereo or a camera, those all I have to be able to use far away from a manual or they're total failures. Yes, that's true. Another reason why they need to be that much better, right? But the car stereo touchscreen, one of the reasons they do that is because they use the same screen for 97 different features.

And the part of me that doesn't want to pay for everything is like, yeah, okay, put it all on the same screen. The part of me that wants to be able to mess with my radio without crashing. Yeah, I want buttons back. Yeah, well, I mean, there's an opportunity to do both, right? You can have a screen and then knobs and buttons below it. And most of the stuff that you need to do while you're driving can just be done with the knobs and the buttons. But you need to design for that. You need to think about that. You need to think about that. You need to think about the fact that the user is not looking at the screen a lot. What tasks are they trying to perform while they're driving?

And what tasks are they only performing when they're parked and setting up, say, their Bluetooth for the first time? And that's where you've got to have a good research team, user research, focus groups, all of that stuff. I want to go more into that. So if I'm an embedded software engineer, maybe fresh out of college, how do I learn about these things? There's a lot of material online. There's books. There's a book, Design of there's books there's a book design of everyday things it's pretty popular um i find that most companies i've been at before did not i mean we were it

was chip manufacturer but even in the cases where they were trying to make a demo product or something, did not take it very seriously. I think Apple has shown us how important it is to do this sort of thing. And now a lot of the newer companies are making products where, yeah, it's a router, but they've worked very hard at the design of it, and they probably have a user experience and user research team. So Fitbit has user experience and a design team. And it's kind of what drew me to them in the first place, because I felt like they really cared about that aspect. They were spending time on that aspect.

And I would get to learn a lot from that. So I would say find one of those companies, you know, the ones making embedded, but actually putting a lot of attention and care into the user experience. And you probably learn a lot from just working at that kind of place. I agree with that. Not everybody gets the opportunity to work at Fitbit. And it is difficult when you are not the intended user of your device. It's one of the things that Fitbit generally has an advantage of is there's a lot of people there who are runners and who just want to exercise more. And so it's very easy to test in the hallways.

But on some of the medical devices I've worked on, I'm not a doctor. And what I want to see and what I want to know may not be what they want to know. How do you, other than saying, yes, we need user groups, which is really expensive when you're talking about doctors because you have to pay them to come in. How do you start doing that, putting yourself in the other person's shoes? So I would say you really do need the real users. I don't think that that can be faked. The way that people work in their work environment is something that other people aren't going to guess at. I don't think that there's an easy backup for that. In my master's program, you know,

we actually got doctors in the Veterans Administration Program to participate in some studies regarding, you know, interfaces that were being designed. And I think that if it's something that's going to make their life better, there might, you know, it might be in their best interest to help you make equipment that helps them out. But I think it's common for engineers to try to put themselves in the shoes and to think what people might be doing. And then that leads us down a path of designing for ourselves. And it's good practice to avoid that as much as possible.

The medical device example is a tough one because I recall when I was working on one, there was this tension between research, where we needed to be able to control many many aspects of the device and the end user the doctors who want to be very very focused on what they're doing and you know present very don't present things that that's going to be extraneous to them or give them options that they're not going to regularly choose and so we had one side of the company that kept saying oh we need this knob to do this and we need 15 other knobs over here and so we had one side of the company that kept saying, oh, we need this knob to do this, and we need 15 other knobs over here. And so we put those in. But then when we went to, you know, a study, and a doctor was using it, it would be overwhelming. We eventually figured out how to

balance that. But that's another area that's difficult is I still have to learn to use the parts of the system to tune it maybe, right? But at the end, the end product is not going to have those tunings. So you've got this branching path of lab versus final product and I don't want to expose too much but I have to expose a lot and that can be very difficult. Yeah, that sounds really complicated um

i think you know there's possibilities to put your device in different modes you know the mode where uh say a lab technician or somebody that sets up the device and who knows all of the other um finer abilities of the device would be able to tune it. And then just regular user mode where it's a lot simpler and there's a lot less confusing stuff. There's also this, I don't know, I had a lightning round question that was, if you have to choose between ease for new users and expert flexibility, which do you choose and everybody was saying

do both and do you think you really can do both or do you think there's a a real solid divide between making it really easy to start and pick up a device and making it incredibly powerful for the person who has been using the device for 10 years i haven't seen very good examples that do both, to be honest. I think by making it simple for an everyday user, you have to hide things. The moment you hide things, that puts them more clicks away from the screen

for the experienced user. And I imagine there might be ways to, for example, Photoshop, I guess, would be one example of that. Photoshop has a lot of settings and a lot of options. And it's, you know, frankly daunting to someone who opens it in the first. It's incredibly powerful if you know how to use it and incredibly opaque if you don't. Yeah. And another aspect of that is that there's something called a mental model, which is what your user builds in their head as their understanding of how everything is working sort of behind the scenes. And people who use Photoshop have like a really good mental model of how everything under the hood works. Whereas a user who looks at it for the first time,

like none of these words make sense. You know, a lot of them actually come from darkroom days. So they really don't make sense to people today. Yeah, dodge, burn. What? Why would I do that? Yeah, like what is this weird hand making a circle gesture? I don't make sense to people today. Dodge, burn. What? Why would I do that? Yeah. Like, what is this weird hand making a circle gesture?

I don't know. When I took a darkroom class, I was like, oh, that's what that means. But yeah, I mean, Photoshop is an example of super powerful, but hard to use.

And yeah, I haven't seen software that's super powerful that is also really easy for new people to get into, to be honest. and people get very upset because they are used to having more options and suddenly they're taken away. So that's another backwards thing that happens is, oh, let's simplify this for everybody. And then, of course, everybody who knows how to use it is upset. Yeah, I mean, I'm a PC person. Partially because of that, when I use a Mac, I'm like, wait, where are all the buttons? I want to do more things.

They're gone. You don't like it. I want to see all the error messages so I can fix things. Okay. So going back to designing good interfaces, how important are mock-ups to that process? The before it even is a board, before it is a prototype, just the paper mock-ups. Do you mean for embedded or for design in general for embedded for embedded user design because i think that's a it is a harder problem than just user design where you just pop everything into flash and say pretend it's real yeah i think they're really important because uh you need to iterate a bit and it's hard to see the problems when you're

just talking about it in words. A lot of things, one of the things that we've noticed is when we design the UI for one of our devices, we'd like to have a navigational model of how everything is going to like, oh, you're on this page and then you go to this and then you go down because it becomes really obvious once you actually try to draw that where things are breaking or where you're going to end up in a state that you can't get out of. And somehow just making it visual makes it easier to see where those flaws are and also to see if it doesn't really make again with the mental model thing people are trying to make sort of a 2d or 3d model in their head when you have an interface or a flow of some kind they're trying to guess uh what's happening

behind the scenes in whatever way they can and i I think making these, drawing these models and mock-ups helps the engineers and the designers see where that mental model is going to break. In addition, once you've, you know, delivered something in code, then the cost of making changes is very high. So it really is in your best interest to make the big changes on paper beforehand rather than after. And people are more likely to tell you this makes no sense to me when all they're looking at is a piece of paper you drew on rather than, oh, here's this polished product we've been working on for like 12 months uh what's wrong with it you know people are less inclined to tell you the truth

at that point because you know they're like well this is what this product is that was true we used to do user testing at leapfrog with the kids toys and they would they would really rip apart a piece of paper, but they would be nice to a plastic model, metaphorically rip apart a piece of paper, but they would really tell us how we were wrong. And I was amazed at how often I could do a state machine, and I do them as tables so that you can really see where the blank states are if you've gotten a certain number of buttons.

And it got easy for me to say, okay, the user's going to do this, this, this, and then they're going to push the up arrow. And you have nothing going on there because you don't want them to push up the up arrow. They're supposed to be listening to the story at that point. But they're going to push the up arrow, so you've got to put something in there. And they'd go into user test, and that would going to push the up arrow. So you got to put something in there and they'd go into user tests and that would be exactly what they're doing. I was so pleased and yet so baffled at why we weren't handling all of the buttons in all of the UI states.

Yeah, exactly. I mean, when people see a button, they want to press it, you know, and then they kind of expect it to do something. You've been in the car with christopher before hey um do you watch users learning to use your products now do you get to do focus groups i do i do sometimes um i used to do it more but um just you know getting busy and having more products it's gotten harder but, we do out of box testing on the user research team does that. And they make the video teleconferenceable. So we're able to, to watch it and see what they do. I think it's really, you know, they're good,

the user research team is going to summarize all the data they get from that and feed that back into the design process. But it's really great as an engineer to watch people actually struggle with the things that you then are asked to change because you really realize the value of it. And I think it's important that it doesn't become like, oh, you know, design wants us to change this. But when you see that, you're like, totally understand that real users are struggling to understand what that icon means

because it looks a certain way. Yes, someday soon, the millennials will come and say, what is this icon that means save and has nothing to do with the world? Christopher will say, it's a floppy disk, Siri, let me show you one. Yeah, I know, they probably have no idea. I think I saw a picture online where someone said, look, someone 3D printed the save button,

and it was just like a floppy disk. But UIs often have designers who don't understand embedded. Some companies do this thing where they get the same designers they used for their website, and the designers don't understand the concept of fonts being limited. Well, it's worse than that. Or update rates being limited. It's understanding the constraints, right? Yeah, I don't know why you can't play MP3 on, you know...

An 8051. Microwave. Yeah, an 8051. Yeah, that's definitely a challenge. I mean, Chris probably knows a lot about this, but I honestly sometimes I want to tell the designers, could you just try to design this in Microsoft Paint and then come back to us? Because that'll give you a sense of how hard it is for us to put together this screen that you've designed. You know, there's like Gaussian blur and light effects. And if you were doing that in paint, you would quickly stop using those.

Well, it's kind of a double challenge because we as engineers have the challenge of implementing things that may be beyond what the system is capable of. We also have a communication problem where it's difficult to tell a design team what is and what is not possible because A, we may not actually know the answer to that question. It may be very vague. You know, you may have some things that are like, well, I guess we could do

that if we maxed out the CPU for a few seconds or, you know, if we did some heroic thing. But B, it's difficult to take very technical things like, okay, I've got this much RAM. That means you have this big a buffer for off-screen rendering or something and translate that into something the designer can do something about. So I think that's where the trick is, is kind of getting on the same page language-wise. Right.

So, yeah, so I would definitely say language is a big one um i think doing the the master's degree in hci kind of helped me a little bit with that because uh at least i feel like i understand what they're talking about i can try to translate you know our concerns to to them but some things are just yeah like chris, just really difficult to explain, you know, why a certain number of layers in a particular UI is going to cost so much time and the size of the bitmaps that we're throwing on there, the number of characters in the strings that we're throwing on there. So one thing that I did for one of our products was come up with sort of a spreadsheet where they could plug in like, okay, I'm going to throw on a background and then I'm going to throw on this font

and it would do some math and come up with like, here's how long it's going to take us to draw this screen. And so from that, here's the best frames per second we can get. And it wasn't, you know, it's just a model. It wasn't a perfect match or anything, but at least it helped them, I think, get to the point where they got that, okay, adding a background and alpha blending something on top of that

and putting characters on top of that, that all of this adds up in a way that results in a worse frame rate. So, yeah, I mean, that's one thing that we've tried to do with them. But it is a challenge because sometimes we can't even really articulate why something is easier than, you know, one design is easier than another. Luckily, you know, we work pretty closely with the designers. So at least we can have a back and forth and just try to talk through some of these problems. So that helps. Most of our UI engineers sit right next to the designer for their product. So they can do a little bit of back and forth and tune for some of these things but it is tough and it's hard hard to know when to say no we can't do that and when to give it a shot because

there were several times that i remember just balking immediately no we can't do that that's that's impossible rounded corners you must be kidding me and going off and in a huff you know spending a week on it okay fine we can do it yeah um so it's it's a little tough to to not be doctor no you know right i know and then sometimes the engineers are the opposite where everything they're you know you ask an engineer can you do this and they're going to say yes because you know of course with enough time and enough hacks and enough like tweaking they'll get some working version. But that'll be all the device ever does.

Right. Is it realistic? Should we be making those, like, maybe fragile hacks or changes that are going to fall apart the moment something else is going on? So, you know, you just have to have a good sense of like the priorities for the product you mentioned your degree um you have a master's degree hci human computer interaction right yeah and that's helpful for communicating for translating from engineer ease into designer ease and back. How else is it useful for the actual embedded development or is it too high level? What I did was I actually had, it was actually a master's in computer science

with a specialty in embedded systems, but I did it interdisciplinary with a cognitive science department, which had an HCI program. And at UCSD, that cognitive science HCI program is much more high level. It's not very embedded. And in some departments, it's in the computer science department, and you really do work on, say, making a violin that's totally electronic or something like that. So it's very embedded. But at UCSD, it is quite high level. And I think what's useful there is the language.

You definitely get better at understanding what the designers are saying and speaking with them. But also, I think that you start to value the process of design and value the importance of delivering a good user experience. I think that in products today, really you know competing with apple um like almost every consumer electronic product is today uh you have to you have to care about these things and you have to do a good job and you have to deliver very high quality product if if you're going to do well and it allows you to you know think about those things but also appreciate, I guess, that whole aspect when you're doing your code. So you could be given an interface and design it but not care that much about finessing certain parts of it

but you start to see the importance of finessing design aspects of the interface after you watch people struggle with using an interface because the icon is confusing or because the button didn't respond right away and responded a second later, but that actually makes a big difference. Yes, it makes a huge difference. I get so confused when the buttons respond too late because I think they're doing other things. Yeah, and then you press two and then, you know, you don't know where you ended up or why you ended up there.

And it has a lot of effects besides, oh, it delayed a bit. Okay, so the other thing I wanted to talk to you about was internationalization. And how you prepare embedded systems for international situations, especially resource constrained systems who have to deal with other languages? Yeah. So the first big thing is when you realize that all your strings are scattered all over your code and you are going to have to fix that quickly. But also there's a need to look at the fonts that you're going to be supporting, the size of the character sets you're going to be supporting, and figure out how much space all of that is going to take and whether you have enough space and what you can afford to support.

And you know a lot about that, Alicia. Yes, some of this isn't fair because I wrote some of the white papers for Fitbit when I still worked with them. Yes. I appreciate it greatly. And to be fair, some of those went up on our Element 14 blog and I am going to put it

on our Embedded FM blog to describe internationalization and devices. But I kind of wanted to talk about it more here without monologuing. So one of the things most English speaking countries or manufacturers, that's not right, producers, people like Fitbit usually localize to the easy languages first, the ones that are most like English. Is that still true of most products, or is that sort of... No, we've been doing Ukrainian first now. Well, I don't want to ask specifically about Fitbit.

It was more like the general. Right. Is everybody still doing, what is it, Spanish? Figs. Figs. French, Italian, German, Spanish. Well, so we've now done Chinese, Japanese, and Korean as well, which are arguably on the tougher side of things.

I think it also lines up a little bit with markets so um emilia you know europe middle east africa i think is one market uh and so hitting french and spanish is really important there and then in german and then the next big markets are China and Japan and Korea. So I think it ties in a lot with wanting to hit the markets where people all speak a different language and would not use an English-based product. For example, India, we sell English-based products there because people there are happy to use products in English. Okay, so let's go through some of the difficulties with localizing. You mentioned strings. Wait, can we go back and define the definition? You've used localization and internationalization

interchangeably. Okay, yeah. Shibona, go ahead. Okay. So internationalization is preparing the product to be able to handle sort of the infrastructure side of things, to be able to handle a variety of languages. And then localization is specifically making it usable for a particular language. So for example, our products are internationalized for Portuguese in that it wouldn't be very hard for all the infrastructure is there to support Portuguese, but they're not localized for Portuguese. We never actually got the Portuguese translations and made a build and made that available in that locale. And so as we move our strings to header files and start giving them extra spaces because those German words sure are long that's internationalization and when we actually pick up a new set of strings that are in

a different language that's more localization. It's the translation part that's the localization. It's the translation part that's the localization. That's how I think of it. Yeah, me too. Okay. Although it's not quite that simple because then you have to deal with numbers and numbers are put in a different order and yeah, it all gets very complicated. But when you start going to European set, the French, Italian, German, Spanish set,

it isn't like you just have to change out some strings. One of the things you have to do or to consider is that there are accents in French letters and you have to either put them above or below what English sees as the normal line of characters. And so you have to make all of your characters smaller, making them look worse, or you have to do some sort of horrific hack to make the French characters look okay. And then you get to German and all of them really are quite long words and they don't fit on your tiny screen and so you do you scroll or do you do you scroll and then pause and it gets very strange it isn't like you just are popping in latin languages yeah um so this is why internationalizing our products has pretty much taken all of my time for the last uh probably eight months or so uh there's like a variety of things to get your

product ready for internationalization like you mentioned there's you know regional settings the way that people use decimal points the way they group numbers larger than a thousand. In addition, there's the font aspect. We got lucky at Fitbit. We actually, when we were doing English fonts, we had already left space above each character. And so when we used the French fonts, we didn't actually have to shrink. We didn't have to do the thing where you shrink the capital letters to make space for the accents. And so in the end, it looked pretty good, even after we switched to the Latin fonts.

But it's also involved educating a lot of people, not only engineering, but also design teams. Now, when we get a new design from the design team, we try to make sure that there's no part of the design that like is depending on the fact that the string in English is going to fit in this spot. They have to make a separate design for what if this is two lines? What if this needs to scroll? What if, you know, and so there's a variety of ways. One is scrolling. The other is, you know, you shrink the font and use multiple lines.

And so very early on when they give us the first design is where we try to feedback, like, what are you going to do when we have different languages how are you going to fit it and so now they're they've gone pretty good at always coming up with multiple line or scrolling designs for all text so that helps okay so what do people have to think about when they're going to asian markets because it's not as simple. Yes. So one really challenging thing is obviously the character set. Some of the character sets are 20,000 plus characters and figuring out which ones are needed. Again, Alicia, you helped a lot with this so that that's a big challenge because you also don't know if you're if you're going to be hitting a pretty good selection if you have a device that where all of your strings are constant like say on your microwave or something that gets easier because

then you can just have the characters that you know you're going to need. But for example, for Fitbit's device, we now show music control and notifications and that strings that are coming from the user. And we have no idea what they're going to be. So we have to have a reasonable guess as to what characters we need on device to support that. In addition, if you're going to use a bitmap font instead of a scalable vector font, then you can only have every size of the character set that you need is going to take up more space on device so if you want uh variable text like notifications in and in one place you're going to show them in font five you know font size 12 and in another place is size 24 then you're going to need that whole character set at both size 12 and 24

on your in your memory which you more than likely don't have space for. Well, I guess it depends on your constraints, but we certainly did not have space for that. So we had to tell the designers, everywhere we have this variable text, music control or notifications, you have to use this one font. Yes, because vector fonts are incredibly expensive to produce at runtime. Yes, exactly. Like you incredibly expensive to produce at runtime. Yes, exactly. Like you need to cache them for sure. Although we do use them on our newer devices. Are there other considerations we should talk about for internationalization?

I think that using native users really soon to test your devices is really important because there's also cultural stuff that doesn't really come up in the engineering or design side of things that will come up when actual users use your device like certain numbers are bad luck or or come across you know they mean the wrong thing in another language or certain translations that you get from your translators are literal, but they don't exactly mean what you need. So another thing that we've put into place is a language QA process where we fly in native speaking country managers from the country we plan to sell the device in. And they actually

go through all of our screens, which on the engineering side means we actually screenshot, we have a whole QA process where we screenshot every screen on device so that we can present it to them and talk through what the screen is supposed to mean. And they can feedback whether they think that's a good translation, whether it works. So that's actually a lot of effort that we need to do. And the other challenging part is it's effort that needs to be done very close to the launch of the product because that's when you have all the screens actually working on device and you can actually test it. And we found a lot of things in these phases that surprised us. And we had to go back in and make a last minute change before we actually launched.

And the majority of it is, you know, you change some strings, which is great. But some things, you know, the way that people arrange dates or times in other countries was something that came up at that point that's sort of heartbreaking to have gone through this design process of getting those corners rounded and making all the layers pretty and and fitting everything just perfectly to make it look really nice. And then to ship it and then to be ready to go on to move something else, but then you internationalize it, which is good, you understand, and then you localize it, and now you're still getting design tweaks.

How do you maintain motivation when you're just ready? I mean, this product is second generation now. No, you cut the lines of communication at that point. Well, I think it comes back to that whole, like, you got to care about the users. You know, you got to care about those customers that are looking at that device and you want them to think it's awesome. And if you're into UI, even in embedded, you do want to think you want them to think it's awesome. You know, just that aspect, I feel like everybody is a, everybody can give you their opinion about user interfaces. So it's its own challenge in a way that you need that user interface to be perfect. You know, like our devices can actually shut down and restart without the user noticing when it comes to the data. But if they happen to be looking at it when that happens, if they happen to see a pixel glitch when they're looking at it, that they're going to notice and they're going to complain about.

Whereas we could probably drop some data and they really wouldn't notice when they look at the graphs later. So in some sense, it's a very high bar for what's good enough when our users look at these devices and you got to care about that. I think one aspect of that too is for better or for worse, Apple has set a certain standard for what people are used to now for a polished user interface,

and I think they've fallen down in recent years in various ways with some of their redesigns. But for the most part, people expect computers they interact with to look a certain way now with touch especially with touch screens iphones and ipads and tablets and whatever and so i recall in previous uh previous work trying to tailor things so they'd be familiar based on that experience and so i don't know where i'm going with that but it's it's it's a different world than it was when, say, 10 or 15 years ago when you had Windows and people knew what that was and they put up with it.

And so they'd put up with a lot of things that you wouldn't necessarily be able to put past them now, I guess. Yeah, I agree. I mean, you know, I've seen little kids like try to swipe a picture frame. People's expectations change pretty rapidly once they get used to something. And, you know, they're used to the way our phones work these days. And they expect that when they use our devices. And our devices are so much more resource constrained and so much lower power, but you know, they want the screen to move with their finger perfectly and bounce and flash. And it's very challenging to provide that kind of experience without the,

without the underlying resources. Oh yeah. I like it when clients say, well, I wanted to act like, I wanted to have the same user feel as an iPhone. And I say, can I have the other $300 in the bomb? Yeah, we're using a Cortex M0. Is that okay? Yeah. Yeah, it's really tough.

We could be responsive if their screen is 5 by 5 pixels. Yeah. Yeah. And just, yeah, color and resolution of things, alpha alpha blending uh fonts hinting of fonts like 3d strokes 3d yes and alias fonts like yeah okay well um this is all very hard so let's talk about something else your job switched from being primarily programming to primarily management about a year ago. Is that right? Yes, that's true.

Or was it longer and more time has gone by than I can think is possible? Yeah, I think it's maybe a year and a half at this point. What has that been like for you? It's been kind of interesting um for a while there we were very focused on the internationalization and that went pretty well because um we were trying to do it across multiple devices and i got to you know make sure that a large number of the engineers were being educated on what it was like knew what they were going to do on their particular product um and make it happen and that was awesome

because it felt like being able to have technical impact in a much larger way than if it had just been me individually contributing to one product and one result. But it's also challenging because when I'm not delivering some larger thing and we're between projects, then on a day-to-day basis, I find it kind of a struggle to deliver value in the way that I know best, which is to write some code and commit some code. And so that has been kind of a struggle. My manager assures me that we deliver value in a variety of ways, but it's hard when you've been an individual contributor for so long to feel that sense of accomplishment when you didn't, like, make either specific commits happen

or, like, drive a team to deliver a larger product or feature across multiple products. So that's been kind of, there's been good and bad. On the management side, I actually like working with people. I like people. I like the people on my team. So that's been less of a concern, to be honest. I mean, I have a lot to learn in terms of management, for sure. We all do. But I've actually enjoyed it more. I like helping my team figure out what opportunities they're interested in or whether they want to lead or not lead or you know and help find those opportunities for them

and did you take some training to get into it or does Fitbit have a program of some sort they didn't before we got promoted I mean honestly it just sort of ended up that I was already driving a team of contractors. And I was in that position almost before it got named. But since then, they have a number of management essential sort of classes that you can take. And so I take a bunch of them there's uh they're little there's a full day one and then there's smaller two hour or morning courses that give you specific skills like how to give good feedback how to coach how to have crucial conversations uh and those are nice because uh you know, it's not like you go

and do like three days of training and then you forget everything that you did. But it's more like little pieces that you can maybe come up with one or two things you're going to do differently and slowly improve your ability to manage your team. That makes a lot of sense. The incremental changes are much more easy to fit in rather than a complete reprogramming of your style, which probably doesn't work anyway. Yeah. And they also, you know, really focus in those classes on like, what is your, think of one situation you're dealing with right now and what are you going to go do differently because of this class and you know go try to

make sure you go do that so they try to like really make it actionable which is great and you mentioned earlier camera interfaces you have a pretty serious photography habit habit hobby sorry sub career and a habit and a sub career Habit. Hobby. Subcareer. Hobby and a habit and a subcareer. What kind of camera? I have a Canon 70D and way too many lenses for it, given that you really only ever end up using one or two. Yeah, I'm really into it.

I've been doing it for more than a decade um i sell some photos on getty which is the stock photography website um and then i also sometimes do shoots for people like engagement shoots or baby shoots kind of depends on it's not i don't really i don't think you should shoot babies um yeah good point i know it's funny sometimes i um i type in things into google that doesn't sound that good knock at your door yes exactly so have you done weddings and whatnot uh not weddings i've actually specifically stayed away from weddings and just sort of specialized well it's specialized and and it's also uh the sort of thing where if you mess up you've ruined someone's photos for the most important

day of their life blah blah blah right so there's just a little too much drama and I just I've offered to be a backup photographer for friends so if they have a wedding photographer I will take another set of shots and like process them and send them to them and so then they have another viewpoint because a lot of times the actual wedding photographer has to take like the group family photos and all the stuff. So they're they're quite busy and they don't get to have some of the more journalistic type of photos. So so I'll do that. But I've kind of stayed away from actually doing the wedding thing because of the you know, I have actually right now I have two cameras. But for a long time i had one camera what

if it froze on the spot a real wedding photographer usually carries multiple bodies multiple lenses multiple black backups and i just don't have that kind of equipment okay so what do you like to take pictures of a lot of different things actually so mostly travel so I like when I travel somewhere to go find places that I like to shoot but that could be anything from landscape to you know like marketplaces and cities urban people so really a variety but I think that when you travel there's a certain everything looks new everything is visually sort of different and exciting So it's really fun to shoot in that environment. The other one I like is actually concerts, like music in an actual venue, because it's really challenging and it's very hard to capture because the musician is moving really fast so those are good too but that one again more challenging because they have to let you bring your camera in and that's not always a given yeah sometimes it's they're not allowed to because

there's some union rules and musician rules and stuff or like they want you to have a press pass or be the person that's been promoted, paid by the promoter to shoot that particular event. How does your photography impact your work life at all? Not really. I think for a while there when I was searching for jobs, I did check to see if there were any photography related embedded positions because I thought I would enjoy that. But most of the camera companies are in Japan and most of them don't have engineers in the United States. Um, so yeah, there was a vague attempt there to see if I could maybe work on a camera. That would be fun.

Um, so yeah, mostly I think it's a diversion, something, another part of my brain, another, another aspect, you know, something to do when I get home and when I travel and go on vacation. Totally fair. I'm not one to say that you should be programming and managing and working all the time. I think that there's good reason to stay away from that. But you should come down and look at our beaches. They're very pretty, very photographic, photogenic, photogenic, that sort. Yeah, I think I've been somewhere near there.

And it was really beautiful. But I haven't been to, I've been to Capitola recently, but not Aptos. It's not that far I know it was really close but I don't think she really likes us that's it the show is over I should have contacted you guys I guess

actually we are sort of out of time Chris do you have any last questions? Well, yeah, but not if we're out of time. It goes back to stuff we were talking about earlier because I forgot to ask it. Well, okay, so I've been doing this a while. You've been doing this a while.

We've all encountered certain kinds of engineers who don't have a high opinion of people who work on UI stuff. What do you say to people like that i know i've i've run into people in the past who's like well you just put images on the screen i mean what's the big deal or or uh or engineers who think they know how to do uis and so you come into a place and they've been working on it for a long time and it's as if they'd written it an adventure game and basic and everything's printfs and so you know each pixel is hard-coded how do you educate our own people about the i mean partially talking on the podcast has done that a little bit because i mean it does sound complex the way we describe it

but i mean just as a knee-jerk reaction, sometimes people say things. Does that happen to you? And how do you react to it? So I don't think it's happened in a direct way. People don't actually say, oh, aren't you bored of working on UI stuff? But you get the sense from the fact that it's actually hard to recruit people to

to do the work because they think of it as oh that must be really simple um i think that a an easy way to sell it is if they actually you know like at fitbit do end up working on our team they start to see wow this is actually pretty. And there's a lot to think about. And so that that's easy. But in other situations, I think a big, I mean, I think Apple is a really good example. I'm not I know, we've brought up Apple a couple of times here. And I'm not even a big Apple person. But they really showed what a difference it made at that time, the cell phone industry was like, we have to make lower and lower and lower cost devices. Because, you know, the cell phone market is saturated, and nobody's gonna buy more cell phones. And then Apple came out with a phone that everybody was willing to pay $400 for. And why? I mean, it wasn't a new uh cell phone technology it wasn't a new it wasn't you know

4g uh it wasn't really what was fantastic was the user interface it was like nothing we'd ever seen before and i think they're a good example of how users will pay a lot of money for that aspect. And people who aren't willing to step up to that game, they're going to get priced out by the people who are willing to play that game. I agree. Yeah. And plus, we all like to use things that are easy to use. Everybody complains about

terrible user interfaces so look at like our you know dvd players and microwaves all blinking 12 12 all the time you know it's so hard there's so many simple things that we just put up with instead of enjoy using i always thought they were in the pocket of big electrical tape. Yeah, I mean, cars actually are a good example too, you know. It's really enjoyable to drive a car, for most people anyway. And a big part of that is like their interfaces are well designed and embedded, but well designed, you know? Yeah.

Somebody had to think about them, partially because you have transportation boards saying, how do we make this safer? How do we make this less distracting? And that means that the designers have to think harder. And as often happens, the additional thought makes it better yes exactly and you know what i said earlier about um there's no room for error in user interface people will notice and people will be annoyed um i think that adds a level of challenge that isn't always there with some other things. Yep. All right.

All right. So, Shimona, do you have any thoughts you would like to leave us with? Just I think that I'm really excited for Embedded in the next decade or so. I think that there's this great opportunity now that there are startups working on hardware products in a way that I didn't see so much a decade ago. And I hope that we get a lot more people getting interested in it because I do think it's really fun and it's fun to make a real thing. It's fun to make a physical thing. So yeah, I'm excited for the field. All right, cool. I'm excited too, of course.

Our guest has been Shimona Carvalho, Firmware UI Manager at Fitbit. If you want a lot more information about the technical aspects of internationalization, check out episode 26, The Tofu Problem with Ken Lund. I seem to recall that was the sort of episode that at the end you wondered where your brain went

because it was a lot of information. And you can get these old episodes via the Libsyn link, which now has more back data, back episodes christopher stop shaking your head well we haven't advertised that anywhere so well that's i was gonna put it in the show notes well okay ah shimona thank you for talking with us today thank you very much both of you and of course thank you to christopher for producing co-hosting but not for like jumping in with these links here and of course thank you for listening did you know we have a blog yes yes embedded fm slash blog it has great information about microcontrollers and c

and software engineering and soon there will be great information about internationalization and cats. It's a rerun. It is a rerun. We also have a YouTube channel for these podcasts, the Embedded FM podcast. So if you'd like to get the audio while staring at a screen full of our wonderful new logo. Okay. Yeah, we made that for you. The contact link on Embedded FM will direct you to the YouTube channel, let you email us, or let you sign up for the newsletter. Every week you get information.

It is the same information you could get on the blog, but that's okay. It's a very multifunctional link there with the contact link. And now a final thought for you. Whatever. Ah, this one from Neil Stevenson's Seven Eves. Remember, these things are designed for amateurs. Tell me about it, Ivy snorted. The user interface is so easy to use, I can't do anything. Embedded FM is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements

in the show, we did not put them there and do not receive any revenue from them. At this time, our sole sponsor remains Logical Elegance.