Matt Legend Gemmell’s Bio
iPad, iPhone and Mac software engineer with a passion for the human side of computing.
- Answered 125
Matt Legend Gemmell’s Answers RSS Feed
-
Who do you respect or admire that no-one else would have heard of? And why?
My father, Matt Struth Gemmell. He's never stopped being interested in things, he knows how to persevere (to a degree that my generation and later ones would scarcely comprehend), and he understands the nature of people. I use all these qualities myself every day in my work.
He also gave me my love of written language, and unconditional encouragement no matter what career path I chose for myself. He has his flaws just like any of us, but I deeply respect his opinion, regardless of the topic. -
What practices do you recommend to weed out as many design/UX mistakes as poss before they are committed to code?
Make sure that coding is the very last thing you do.
The majority of visual/interface and UX design can be done before you have to go anywhere near specific-functionality-level code, and you can have a much more agile and responsive design process if you're not juggling both aspects of your software.
Lean heavily on prototypes (particularly low-tech, scribbled-on-paper mockups), and don't make the mistake of having static sketches - your interface is a living, changing thing. Draw all the states. Pretend to click things. Prototype the interface/experience for the _whole workflow_, not just the initial appearance.
You can eliminate 90% of your problems by getting it all nailed down before you've written a method, and you'll save an incredible amount of blind-alley coding too. -
As someone who works with interfaces, are you ever completely satisfied with the experience of apps you use on a daily basis?
I think that graphic designers probably have more difficulty sleeping than I do; I don't obsessively notice imperfections. Problems with interfaces do annoy me, but I'm more interested in raising the general, average awareness of this discipline than in chasing a vague ideal. I see more and more apps these days that each have some tiny little wonderful touch in them, and that delights me.
To answer a slightly different question, I'm very satisfied that people are more aware of quality user experience, and that customers are more willing to demand it, and blame the designer rather than themselves when something doesn't make sense. -
Which books about GUI Design and UX would you recommend to an experienced programmer with little formal knowledge about those topics but highly interested and passionated about them ?
About Face 3 is a good read, as is Tog on Interface, but this isn't a discipline you learn by reading; concentrate on your feelings, and then think about why you're having them.
We all experience delight and dismay when using software interfaces - teach yourself to recognise those moments, and then step back and critically analyse why you're having that response.
User experience/interface design is about the word they have in common: the user; a thinking, feeling human being. You're already one of those. Listen to your own responses, and let them shape your decisions to an appropriate degree. The only irreplaceable qualification for this line of work is empathy. -
Have you ever needed to design an interface for an app that you wouldn't personally use? If so, how did you go about making it?
All the time - I'm a consultant UX designer and software engineer, after all.
The first step is always to try to become the user; get into their mindset and see their perspective. It's the only way to do any useful work, because what people actually want (note: not what they _say_ they want) is far more important than your rarified vision, particularly if you're not in the target demographic.
Client interviews, surveys, use-case construction and so forth are all useful tools, and they're well-documented and well-understood. However, I'd caution against relying on them completely. Once you have some experience, you'll find that your professional judgement is the most reliable modulating factor for software design.
As I've said elsewhere, I'm also a big fan of pencil-and-paper prototyping, regular revisions and very regular client feedback. -
"Modesty is Lying" - can u explain this?
It's a humorous reference to my self-aggrandising online personality (which is why I use it as the tagline of my blog). In a sense, given that modesty is downplaying one's own abilities and achievements, it is indeed lying.
It's a (not at all serious) possible "righteous justification" of complete immodesty, which appealed to me. It was something I said spontaneously a number of years ago when Lauren rightly accused me of lacking modesty, and the phrase stuck. -
I would like to ask you about the software design phase. Where to start? (Classes, objects, models, etc) How to start developing a new project? (From concept to code.)
I recorded a World According To Gemmell segment on that very topic: http://www.mac-developer-network.com/shows/podcasts/mdnshow/mdnshow021.html
-
Matt are there any bookmarks/blogs/sites that offer tips on preparing a great presentation you'd suggest to new presenters about to be thrust up to the lectern... Any bookmarks or links would be really appreciated - Cheers.
I don't know about resources on the web, but I can give you some tips that work well for me:
1. Rehearse fully. Don't just rehearse sections of your presentation; you have to start a timer, then give the entire presentation at normal speed, complete with all your jokes, anecdotes, demos are so forth. If you screw something up, just keep going.
If you find the presentation is running long or short, cut material or add new material, and rehearse again. Repeat the process until it's the right length. Now you have your actual, final presentation - rehearse _that_ fully at least 3 times. You'll deal with 95% of all presentation problems by following that tip.
2. Make eye contact with your audience. Don't just read; you should have rehearsed enough that you don't need to read everything.
3. Don't do demos unless you really have to. Don't demo anything that isn't under your complete control.
4. Don't write code during a presentation. You can show some code if really necessary, but it's better to distill the essentials into a slide, suitably syntax-coloured and annotated. Don't EVER debug during a presentation. Stick to ideas, slides and charisma wherever feasible.
5. Don't just serve up slides loaded with bullet points. If you really _need_ to deliver a slide with 6 bullet points, use 3 instead and just _say_ the other 3. Your audience wants to be engaged. Your slides are just the foundation of your presentation - they're not the presentation itself.
6. Make yourself comfortable. There's no rule that says you need to hug the lectern for the whole hour or whatever. Ask for a radio mic and a clicker and really use the stage. Wander around, speak to different parts of the audience, use your entire body. Point and mime and act and wave; put some energy into what you're doing, and your audience will reflect it back onto you. I always refuse to do lectern-bound presentations.
7. Remember that in almost all presentations, you're making points rather than conveying data or teaching APIs or such, per se. Make sure your point is clear, and convincing. Your audience will forgive everything else, and won't lose any benefit.
8. As with everything in life, care about what you're doing. Any topic that people will attend a presentation on is a topic worth caring about. Do your research, figure out your position, and put it forward with enthusiasm. Even put forward both/multiple sides, but make sure it's with every bit as much enthusiasm.
As the usual stuff: try to stay calm, but remember that nervousness is normal and often healthy. Try to enjoy the experience. If you're very nervous, remember it's only a small period of time on one day, and it'll be over before you know it. You wouldn't have been asked if someone didn't think you could pull it off, and you really _can_.
Get your message straight, rehearse it until you could do it during a power cut, get up there and get it done. -
Being a rockstar of the developer world, do you ever plan on releasing a complete application, desktop or mobile under your own name? I think it would be immensely popular.
Yes, you'll see at least one this year; first one is for the iPad.
-
What's your opinion on Mifi devices? especially for using with wifi only iPad
They're a compromise. If you already have a wifi iPad, then they're a good idea. If you're still wondering which iPad to buy, I'd fully consider your options. Mifi (etc) devices can be faster than the 3G iPad's cellular connection (I believe), but their battery life isn't even remotely as long. Mifis also take longer to start up, find a connection and just generally "get working" than the 3G iPad's connection.
Honestly, if the extra money isn't prohibitive, I'd strongly advise getting a 3G iPad. You're going to want the iPad to be the only tech you carry, and overall I'd say a wifi iPad + Mifi is a poor substitute for a 3G iPad. Fraser wrote a blog post on the topic too:
http://speirs.org/blog/2010/5/29/of-3g-ipads-and-mifis.html -
Twitter app of choice on Mac/iPhone/iPad?
On iPhone, "Twitter for iPhone" (used to be Tweetie 2). I'm actually happy with that one.
On Mac, I keep going back to Tweetie, but it's incredibly old and busted now; can be really annoying. I also periodically flirt with Echofon, YoruFukurou and Kiwi. Of those, probably Kiwi is my favourite.
On iPad, I mostly use Twitterrific. It's not perfect, though; it doesn't autorefresh and (critically) it doesn't even attempt to check if I have mentions or DMs unless I explicitly switch to those timelines, which is a bit of an antiquated approach these days. TweetDeck has a horrible UI and isn't as stable, but it does let me see my followees' timeline and my mentions simultaneously. Twittelator has a very fun UI, but it sacrifices vast amounts of screen-space just so it can draw all the cute surroundings, and that gets grating after a while.
The only platform on which I'd say I'm actually happy with my chosen Twitter app is the iPhone. Jury is still out for Mac and iPad. -
What do you do to feed your family? don't tell me that your MGTwitterengine has made you a millionaire!!
I'm a self-employed software engineer; you can hire me as a contractor or consultant to work on your iPad, iPhone, Mac or other software. I specialise in usability and interaction design, and most clients hire me for custom GUI design and implementation. My business site is at http://instinctivecode.com/
I've worked with many clients all over the world, including (more than once) a certain company that makes very popular and desirable computers, music players, phones and now also tablet devices. -
how long did it take you to finish the "10 touch" iPad project? BTW, thanks for sharing :)
You're very welcome. I wrote most of it while Lauren was watching an episode of Glee on TV, then put some finishing touches and tweaks on it later. A couple of hours altogether.
-
You've recently imported an iPad from the US. Do you have any advice for someone doing or planning the same thing? Any things to be aware of or problems you encountered?
It's definitely an option to consider. Apple's warranties on portable devices is worldwide, so you can use your own country's Apple Stores or other services if you have any issues. Regarding the import process itself, be aware of taxes and import duty for your country. If you're in the UK, you won't need to pay any import duty as long as you make sure the package is appropriately marked (you probably want it to be marked "laptop", which carries no duty, is accurate for the purposes of Customs and is easy for them to understand). In the EU as a whole, you will of course pay VAT on top of the combined purchase and shipping price.
Your iPad will work just fine, wherever you are. Certain apps (like the iWork apps) won't be visible in your local App Store until iPad is officially released in your country, but they're a minority - and you can always buy them on your Mac or PC with a US iTunes account if you have one, then sync them to the iPad. Same applies to the App Store on the device (it'll only work if you're signed into a US account), and to the iBooks Store (is currently US-only) - but those will all start working fine as soon as iPad is officially available where you are and/or when the iBooks Store becomes available in your country.
iPad comes with a standard Apple design of power brick: the actual transformer itself in a little white cuboid, and a detachable country-specific plug (a US one in this case). You do need to use the power brick included with iPad (it needs more power than an iPhone or such to charge), but you can plug any country-specific plug section into it and it'll work just fine; I use my iPhone's UK plug-adapter (rated 2.5A) with the iPad's power brick. You can also charge it via USB to your Mac, though that'll be a lot slower.
Generally you won't have any issues at all; it's the same iPad regardless of where you get it. If the cost to benefit ratio of importing it works out for you, by all means go for it; there's no downside that I've found. -
Is it possible for you to love yourself any more?
To answer in the spirit in which the question was asked: I wouldn't have thought it was possible, but if anyone can do it, it'll be me.
Slightly more seriously: love is a strong word. My online persona is a caricature of reality, not reality itself (I doubt I'd be in a relationship at all if I was actually the way I come across online, for example). Having said that, I do genuinely _like_ myself. It takes years of effort to reach that stable position, but it's happened and it's an enormous comfort. There are enough obstacles in life without your own self-doubt being one of them. -
If you had the ability to create Mac applications before having to make a choice about higher education, would it be unwise to rule out university in favour of the 'indie' lifestyle? Could what you gained from studying at university be gotten elsewhere?
If you have the option to attend higher education, do so. There's so much more to the experience than just the academic content specific to your discipline, and indeed there's much more to it than academia as a whole.
Our industry offers a rare opportunity to begin meaningful work very early in life, and to build a business with little to no capital. That doesn't mean that you should bypass college or university and jump straight into a career. There's plenty of time for that, and you can work on your software to some extent whilst you embark on a degree. You can write software for the rest of your life, but you only have one chance to attend college or university at the same age as all your peers.
For the social aspect, for your personal growth, for the experience of being in an institution that allows you to take full responsibility for your learning, for the perspective and enrichment it offers, I would strongly recommend you pursue higher education. The benefits are enormous, and will take years to become fully apparent to you. -
Any hints (any at all) about the component you plan to release? My hope is an excellent, customizable rich text editor with Gemmell Inside™.
I'm afraid it's not a text editor, but it is a GUI component for the iPad and it is customizable. More details soon.
-
do you have Herman Miller chair?
No, I use a black Ikea Verner; I've had a few of them over the years. I'd certainly like to try an Aeron, but I don't see the need for it right now.
-
Do you approach the design of a UI component that you will make available to other people (either free or for sale) much differently to if you were just using it in an app for yourself? If yes, any advice?
I spoke about this to some extent at NSConference 2009. There are really two things that are going to differ depending on whether it's an in-house component or for release: default behaviour, and flexibility/configurability.
My stance is that any UI component should be designed such that it's not coupled to the project you created it for, and that it should at least display _something_ by default. Use the existing AppKit classes as a guide, and maintain loose coupling with delegate protocols, well-designed/named API methods and notifications where appropriate. Remember to always pass the control itself as a parameter to delegate methods (so the receiver knows _which_ control sent the message), and consider whether it might be useful to do so in the userinfo dictionary for your notifications. Prefer mimicking APIs that other developers will already be familiar with (such as standard data-source protocols like "tell me how many, then give me each one in turn", or the "should/will/did" permission and notification pattern).
The default behaviour for an in-house component can be exactly you need it to be, but the default behaviour for a released piece of code should be whatever seems most generally useful or applicable. Put some serious thought into the average use case. If someone sees your control and decides to download it, what are they expecting it to do? Does it actually do that thing? If it's reasonable to assume that your control does a particular thing by default, make sure it actually does do that thing.
Regarding flexibility and configuration, it's important to strike a balance between limitations and the spaghetti code that comes from unlimited configurability. Let common sense be your guide. Try to keep in mind that if you design your API correctly, and factor your code into appropriate methods, anyone wanting to do serious customisation can subclass instead of calling dozens of configuration setters. Decide what options will serve 70% or so of the usage situations you can think of, and provide those options. Let your API design serve the rest via the ability to override methods in (as thin as possible) subclasses.
As a final note, if you're doing a lot of custom UI work, keep a sticky note someplace to remind you to consider the big 4 commonly-forgotten factors: Sizes (most controls come in three sizes; yours should too), Variants (your control might benefit from standard variants, like rounded textfields), Resolution (try to make your drawing code resolution-independent), and Accessibility (it's easy to provide a basic level of accessibility support, and it makes a huge difference to a lot of people). -
The "slide to unlock" screen works well enough for the iPhone, but seems like a joke (and a massive waste of space) on the iPad. What (read-only?) information would you put there if you were apple? What would you change about the home screen interface?
The lock screen can indeed be a bit spartan, but it's a transient thing before either unlocking the device or allowing the screen to automatically deactivate to save power. It already shows the date and time, your wallpaper (or currently playing album artwork), and the most recent notification, if any. The larger iPad screen does potentially open up some space for additional info, but it would have to be completely optional. If I had to pick one thing, it would be a queue of the last few notifications, with a slightly richer display than the default alert-boxes we have now. Having said that, a bit part of the iPad's beauty is the very austerity of its interface. I'm not sure I'd enable a dashboard-like lock screen. As a separate app, maybe.
Regarding the home screen interface, 4.0 makes quite a few changes; it adds customisable wallpaper, and "folders" (stacks of apps). The only thing that particularly annoys me about the home screen (springboard) is reorganising apps between pages; it's slow and error-prone. I've always wanted the ability to drag an app up into the statusbar to show an Expose-like view of all 'pages' of the springboard, then drag the app back down into one of them to zoom into that one, where I can then drop the app exactly where I want it. Like spring-loaded folders on OS X.
The other bigger question is whether you want your default home UI to be a list of apps in the first place; many devices don't have an app browser/launcher as their default process, instead opting for a task-based gateway UI. I think that iPhone OS is easier to learn and it definitely saves plenty of taps in the average case, but there's also only so far you can go with a simple grid interface.
