Desktop First UX Summit 2021 – Learn UI & UX from Industry Experts for Free

I remember the day Apple’s Steve Jobs announced the iPhone. Steve was a genius of presentation. He was P. T. Barnum incarnate, reimagined for the digital age. He said “I am announcing three products today; a widescreen iPod, a revolutionary phone and a break-through internet device… and we are calling it the iPhone”. It was a superbly ‘Steve’ performance, dripping with the braggadocious drama he was so good at and peppered with pregnant pauses to give the audience time to applaud and to let the import of what he was saying sink in. That event, accompanied by a soundtrack of excited whoops, was a genuine inflection point for the tech industry; a truly capable hand-held computer was being launched. The fact it was a phone seemed almost secondary. Had it been anyone else other than Steve Jobs would it have been the success it became? We will never know, but it’s hard to imagine the same stratospheric launch taking place to the more monotone vocalizations of the financially successful but decidedly less svelte Bill Gates.

The development world turned upside down

This was definitely the future. Here, in my palm, was a device which seemed like what the industry had been searching for. It was compact, comparatively powerful and it had been graced with the design genius of Jony Ive shaped by Job’s legendary ascetic minimalism and impeccable eye for infinitesimal detail.

The years immediately following that very first iPhone launch was a blur of iterative improvements to the mobile phone industry. The app store launched itself on the development community. The premise -and implied promise – was that this was an obviously innovative direction, fulfilling what we had all been led to believe would be the future of computing by the likes of Star Trek, Dr Who and almost every futuristic predictor there was. The iPhone was the beginning of what would surely become Captain Kirk’s hand-held communicator and Dr Spock’s tricorder made real.

Other companies thought so too and quickly tooled-up to emulate the iPhone’s sleek looks and ‘it just works’ interface. Desktop would be gone, quickly too. Google panicked a little and then joined the party with their own Android O/S.

If you don’t go mobile, you’re finished?

As developers, we were given stern advice that we should prepare ourselves for a near future where mobile devices would dominate. Then tablets turned up and the iPad joined in with such eye-watering success that even the mighty Microsoft wobbled fearfully, believed the end of the desktop was nigh and frantically started to redesign their beloved Windows O/S so that it could be shoe-horned into a mobile phone. Except that “Windows Phone” turned out to be a bridge too far. Those that used it loved it but the devices suffered from an apparent lack of conviction from inside Microsoft.

Accompanying that frenetic whirl of activity was a loud chorus that we developers really ought to be designing for mobile first. The perception, in some part led by the hype and seemingly non-stop succession of mobile device product launches, was that mobile was the future and the desktop was a dead end.

The app store gold rush

Apocryphal tales wafted around of indie developers – one or two person startups – who had made shockingly large amounts of cash off the back of a mobile app they had churned out after pulling three straight all-nighters fueled by little more than industrial-strength caffeine drinks and ramen noodles.

Everyone with a budget who wanted to be a ‘serious player’ in the development industry jumped on board.

But the initial buzz of gung-ho excitement faded and a little bit of reality set in. The realization of what even the most expensive mobile devices couldn’t do trumped the heady excitement of being able to sit in a bar and Google whether Die Hard was really considered a Christmas movie.

People wanted to do actual useful things beyond using their expensive phone as a torch in dark parking lots.

The broken break-even point

Coupled with this was the fact that creating mobile apps turned out to be a race to the bottom for profits. The average price for a stand-alone mobile app was between 99c and $4.99 USD. To understand what that means to the viability of a career as a mobile app developer take your monthly household bills, rent or mortgage and taxes. Add them all up and then divide that number by $5.00. Now reduce that number 1/3 to allow for Apple’s cut of the app price. The resulting number is how many apps you will have to sell every single month to meet your outgoings. Even with the vast exposure of the Apple and Google Play stores you have an uphill struggle to fame and riches simply by charging for someone to purchase your hard work for use on their phone.

Very quickly the software as a service business model and carrying in-app advertising became the obvious way to turn a profit. Meanwhile desktop apps sustained – and still do – a price point an order of magnitude more than the average mobile app.

Subscriptions and advertising as a viability proposition

Things started to happen. Twitter, Instagram, and Facebook all made sense on mobile devices. Maps became a killer app. Suddenly, we could navigate with unerring accuracy thanks to the invention and inclusion of cost-effective GPS location hardware into your mobile phone or tablet.

This mapping, combined with the ubiquitous internet which had evolved under the pressure of consumer demand for their portable devices to continuously connect them with the outside world, also meant that other new services and applications could spring into life.

All at once Uber zoomed into our phones and in the process almost dealt a death blow to a traditional taxicab industry who had snoozed at the end of their landline telephones.

It really did look like that rectangular plastic desktop computer was being edged out to the sound of mobile alerts, Crazy Frog ringtones and the swish of swipe to unlock gestures.

Except that’s not the reality.

Slick advertising and venture capital

Oh, sure, if you listen to the schmoozing of a cell phone advertisement and allow yourself to be drawn in by the mellifluous honey-dripping voice-over which oozes soft words in an effort to convince you your life is currently ruined by your use of last year’s device which is now so cruelly sub-par then it’s very hard to believe that your mobile phone will not offer a solution to every task that can be put to it. In fact, the sunk cost fallacy means that the more we pay for our expensive mobile devices the more we really feel we ought to do with them.

But don’t believe it for a minute. Desktop still rules the roost when it comes to business – both small and large.

Let’s take, for example, Uber, who we mentioned earlier. They have been phenomenally successful with their mobile app. The design, targeted squarely at a hand-held mobile cell phone, is succinct, has no fat to trim in the flow of the screens and works extremely well. Their entire business model is rooted in the existence of reliable, ubiquitous mobile devices.

Like many strongly-funded companies of its ilk Uber helps attract and retain its office staff – people who work on the business of making Uber work at the company administrative level as opposed to drivers – through a mixture of competitive remuneration and cultural niceties. Helpfully they have public YouTube videos and images of what a great place it is to work there. But take a second to look at the pictures of the smiling Uber worker faces and you’ll notice that beyond the cool tech surroundings there are a whole bunch of screens. Desktop screens. A whole sea of screens. Modern, flat-panel with thin bezels but desktop screens nonetheless. Granted, many laptops too – but the fact is that Uber, the mobile success story that it is, still uses desktop devices to get the work done.

Desktop First UX Summit 2021

Interested in how you can start putting the desktop first? Desktop UX Summit is offering free tickets.

>>Get yours today!>>

Your mobile app company thrives on desktop devices

Don’t get me wrong, I am not singling out Uber or in any way being critical of them, quite the opposite. This preponderance of high-end desktop displays is played out again and again at almost every mobile app or blue-chip company you wish to examine. Instagram, trend-setting doyen of photography as a statement, was born and lives on mobile devices of increasing camera resolution. Yet, make a brief web search for “Instagram office culture” and you find many hundreds of pictures of what a gloriously avant-garde place it is to work, where you will be overlooked by beautifully arty neon signage and couch-sized fluffy clouds – and many MANY desktop screens and laptops. TikTok, just the same: desktops and laptops everywhere; just take a look at their careers page.

The business of the mobile app business takes place on desktops and laptops, even if you are a mobile app developer who lives and breathes the nuances of cell phone notification SDKs.

This is why the iPhone is not the only Apple product

Even though Steve Jobs knew that the iPhone was a Really Great Idea he went on to draw out a famous four box matrix: professional, consumer, desktop and portable. From that came the MacBook Pro and the iMac. He knew the two facets of the business had different design paradigms and those two complementary opposites had a suitability for differing uses.

When considering your app design remember this truism; design for desktop does not equal design for mobile. Also, don’t make a mobile app which tries to shoe-horn in every single desktop feature – this is an antipattern which will end in an unsatisfactory experience for the end user and an app which will ultimately flounder. If you don’t believe me, try viewing a spreadsheet of anything more than a simple column of numbers on your mobile phone – not going to happen, trust me.

If mobile devices are going to be the future then why is it there is an undeniable trend for desktops to have multiple screens and for those screens to be flatter and thinner each iteration but also taller, wider and with an exhilarating number of pixel resolutions? Clearly, we want more information packed onto our workhorse computers, not less.

When mobile device screens boast of increased pixel depths it’s usually to emphasize that the tiny text on the screen will be crisper and not that there will be more information shown. Even laptops can commonly support multiple external screens; some even have a slightly incongruous second screen built in as a pull-out flap. For those laptops which are gracing desks rather than laps it’s common for there to be docking stations to make the compromises of a portable design aesthetic less of an inconvenience when function is foremost.

Laptops are not mobile devices

Laptops are becoming more powerful but they are essentially creating a mobile desktop for a road warrior, not a mobile device per se.

Where do we draw the distinction? When does a device become a mobile device and what does that even mean?

A modern mobile phone is getting lighter and less cluttered, with fingerprint sensors and other biometrics built into or under the screen itself. But those are additions which suit the use case of a mobile, not a fixed-place device. Even though it is an economically insignificant cost, most desktops do not include biometric devices such as a fingerprint scanner and it’s also uncommon to find a desktop machine with a hardware GPS sensor built in.

The increase in processor power for the mobile device is spurred on by a few factors: advances in miniaturization and technology, cost economy due to scale and the need to drive those larger screens and must-have always-on internet connection. That extra mobile processor grunt still does not grant you, the app developer, the same kind of freedom to design sprawling memory hungry apps which have a lifespan that extends into days like it does on a desktop. Your typical mobile app does not have an expectation of a runtime which is longer than minutes.

Desktop apps, unfettered by battery and miniaturization concerns, harness gigabytes of free physical memory and can expect to find huge swatches of screen real-estate, increasingly over multiple screens, on which to display their data. Processing can occur on multiple CPU cores, both virtual and actual. Desktop background services can easily be written to provide essential additional functionality such as updates – on your own schedule, not Apple or Google’s – and, if installed directly from your site there’s no commission to pay to an app store owner.

Autocorrect exists because our fingers are too big

If you still think you can design an app for mobile first and then translate that to desktop, consider for a moment the difficulty you have typing long emails into a mobile phone. You may be a master at the touch keyboard but I bet you’re faster and more comfortable on a full size QWERTY keyboard.

Microsoft’s Outlook App is an example of the contrast between mobile versus desktop design. The Outlook desktop app is almost certainly the communications tool of choice for most corporations. Love it or hate it Outlook, or a near clone, is used to send and receive billions of emails a day, schedule meetings and keep track of essential contacts. It has a powerful rule processing engine and can embed or incorporate all sorts of essential data. The Outlook mobile app? It’s a weedy shadow of its desktop brethren and with good reason: it’s doing exactly what it needs to do and is appropriate to do on a mobile device – and no more.

Have you ever wondered why swipe left is still hard to do with a mouse?

You can’t swipe in the Outlook desktop app, unless you are using a touch tablet like the Surface Go and even then it’s a non-obvious thing to do. Instead, you point with your ‘pointing device’ whether that is a mouse, trackball or touchpad.

You tap things on phones, you click things on the desktop.

You can choose the look and feel of your desktop app, have menus that make sense to you and a navigation capability which works for those mice and clicks – not one prescribed by Apple or Google or even Microsoft if you really want to go off into the app design wilderness on your own. Microsoft may not like it and changes to Windows or Linux may make your app unusable but you get to plough your own artistic furrow without fear of reprisals from an app store submission reviewer who places your hard work into a sin bin until you comply with their ever-increasing app store ‘guidelines’.

If we lived in an alternate reality

Would Outlook have been as successful if it had been a topsy turvy world where mobile devices came first? With its quite capable but limited feature set: email (no rules or filters), calendar and just a search tab – would it have been a driving force behind Microsoft’s business sector profit center? I doubt it.

And what of Microsoft Outlook mobile – what does it do? It connects you to your email. The email, which is also on your desktop, where all your documents are, where your accounts program lives unconstrained from mobile CPUs which are still too puny to multitask to good effect.

You cannot phone your customer and read out the contents of an email to them on the same device at the same time.

If you’re smart, then the approach is to design for desktop AND mobile. One is an adjunct to the other and both have very different design goals and user stories.

For us, with Delphi, this means to find the back-end commonality and functionality. Separate and ‘decouple’ your interface from your implementation. In real terms this means that you adopt the sound approach that is almost imposed on you by the RAD Studio IDE: model-view-model and controller. The Delphi language has the tools to make this kind of thing happen and the RAD Studio has multiple capabilities to smooth the process and get your great ideas in front of customers with the fastest possible development times of any tool I know.

This is going to sound like the things you’ve heard before – but this is because it’s good advice.

Do these things to increase code sharing between desktop and mobile apps

To get technical for a moment; code to interfaces (and by that I mean IInterface) instead of concrete classes. The user interface for the desktop should not be the same project as the one for the mobile app. Both can share the interfaces. They can also both share common classes. They might even share some kind of database middleware, with caution.

But the database fetching and updating for a mobile device is a whole different game to that of a desktop. The desktop can often assume the database source is likely to be around. The mobile app should best assume that not only might the source of the data be unavailable but that even if it is the amount it can pull in and cache is limited.

Graphic resources, fonts, connectivity, hardware – all look and work differently between mobile and desktops and even individual implementations such as iOS and Android. Lifespans – when the app’s host device might power off or update – are totally different.

Even the rules of what you can show in terms of advertising links and in-app on-boarding of new users can be constrained on mobile by quite heinously restrictive rules.

So, desktop first means business first

Your desktop might be a laptop or a hybrid device like the Microsoft Surface and it may be running macOS or Linux instead of Microsoft Windows but it’s still not a mobile device like a phone or dedicated mobile tablet. Let me know how you get on with that nine page sales spreadsheet on your smart watch.

Desktop first doesn’t mean immobile. It just doesn’t mean a mobile, first.

Did I pique your interest? Then join me, for free

If this article has raised in you some thoughts on desktop-first as a strategy for business-first and on how to generate and sustain profitability as a software developer then why not join me at the upcoming Desktop First Conference? It’s completely free and I will be presenting there along with some really great authors, speakers and developers who will cover this and other related topics at all levels of experience.

>>Head over and get your free ticket to the Desktop UX Summit!

Leave a Comment

Your email address will not be published. Required fields are marked *