Mobile Considerations in User Experience Design: “Web or Native?”


Our spanking Groovy Books #3 and #3⅓ have been released last period and we’re sincerely grateful for the tremendous feedback, reviews and photos submitted by our truly smashing readers across the planetary. We appreciate your event and your interest, and thanks all for your support and esteem.

Today we are happy to present a yet another sample chapter from the book. Within his chapter, Aral Balkan explores what “native” actually means, what options designers and developers have and gives practical advice on what you need to know when deciding on tools all for your next mobile-optimized project. The taster is too available gratis download in PDF, EPUB and MobiPocket or .NAUGHT next to all files.

— The Smashing Editorial Team

Smashing Book #3: the cover of Aral Balkan's chapter
Printed via Aral Balkan, reviewed by Josh Clark and Anders M. Andersen. This cover doll in the Smashing Book #3 was designed by Kate McLelland.

As you probably know, user experience designing is the discipline concerned next to all aspects of the design of interactive products. Tho` it incorporates important elements of graphic shape and happening design, it is primarily concerned with the design of interaction. Its nearest cousin in the design realm is goods design. As user experience designers, we design practical products. Furthermore, since munition design and software design are so intrinsically linked and inseparable, the line that separates commodity image from interaction design — if it exists whatever — is a faint one.

A Web Designer Is a User Experience Designer

Essentially, a Web designer is a someone experience designer with specialized knowledge of the medium of the World Wide Web. The materials of a Web designer are the core (HTML, CSS, JavaScript) and auxiliary (LITTLE, Stylus, etc.; HAML, Jade, etc.; jQuery, MooTools, etc.) frameworks of the Pattern and the components within those frameworks. These frameworks and the components in them are made of code. It is this code that determines the design confines and behavior of these materials.

Designing an application is element much nearly drawing a pretty picture of an application as designing a car is astir drawing a beautiful picture of a saloon. Just As an automotive designer essential have intimate knowledge of the various materials that walk into making a car, so too must a Web designer understand the materials that go into a website or application.

As interaction designers, we’re interested not simply in the aesthetics of AN interactive doubt but in how it behaves. This is particularly important when you’re designing applications (which are behavior-based objects) as opposed to designing documents (which are content-based objects).

Designing Documents vs. Designing Applications

Even designing interactive documents well — particularly within a responsive manner for the Web — requires specialized knowledge. At a bare minimum, it involves an understanding of responsive image principles and progressive enhancement. Drawing pretty pictures, against the other hand, is art, not design.

Interactive products or applications, however, are a completely different ball game. Artful for an interactive medium requires skills in graphic design, motion design and, most importantly, interaction design. The most important feature of AN interactive product is its interactions. These interactions are constructed in code.

Unfortunately, due to increased specialization on teams, the role of Web builder and Web developer has been artificially separated. While such a separation may be required when in use on a squad, these labels should mark out the current tasks of the team members, not sandbox their knowledge. You might focus on certain areas more — especially in particular projects — but you must understand that the primary reason we figure products is to satisfy user needs and that every role on a development team has an result on the mortal experience. This is reason working within small interdisciplinary teams is vital, where every member is responsible for e`er thinking of the user first.

Designing for the User First

When building a product, design leads development and development informs design. This is a cyclical, iterative process in which the goal is to continually improve the product to better touch the needs of users.[1]

Every decision you gross for your product should stem from the user. You essential surmise of the user’s needs first, before considering your own desires. In other language, practice what we call “outside-in design.” Think about the user’s needs and their context, designing what the user faculty see and interact near, then go about decisive how to solve all the problems that creates for you.

Outside Within Is Good, Inside Out Is Evil.

Is your firstborn question in a new project which server-side technology you will spending or what your database schema will facade like? Stop! This is a wrong approach. You’re trying to solve your own hitches, not the user’s. That’s inside-out design, and that’s a Very Bad Thing.™

Purpose of This Section

Two of the core decisions you will need to make during the designing process is whether to make the product cross-platform and if it should be native.

The purpose of this section is to empower you, element a user experience designer, to understand your medium so that you can reply these questions informedly, starting by looking at what exactly we mean by an application being “native.”

Yes, a huge number of devices are out there. No, your application does not have to support all of them. Focusing on the user means identifying your target audience and optimizing your applications for the platforms and devices they use. Supporting a large number of platforms via progressive enhancement is easier if you are primarily building content-based websites as opposed to behavior-based applications. (Image: David Jones,
Figure 9.5. Porting Feathers to Android would ask making different versions of the custom keyboard to support oodles different keyboard types.

The compromise would be to make a single custom keyboard and use that regardless of the user’s system keyboard. Of course, it would neither look nor desire the main keyboard and thus wouldn’t provide the same unseamed experience of Feathers on iOS. Or else, users of the app would have to memorize to use ii different types of keyboards in the app and should exert cognitive effort when switching from one to the other.

Similarly, on homegrown platforms that do not have a active, consistent visual language and culture—such as Android—or on native platforms that are notorious for being confusing to use—such as Windows—non-native applications will have less of a handicap. They might even provide better usability and user experiences in some situations.

A great instance of a non-native application providing a better someone experience on faultless original platforms is Gmail. Using a desktop mail case against an operating policy (OS) such arsenic Windows could involve you to find and install the application itself, keep it updated, keep your mail synced between your various tendency, and make sure messages are checked for viruses and otherwise malware. Compare that to the simplicity of Gmail, within which you go in a URL within the Web browser of any device and — boom! — you have your message. End of story. Gorgeous.

The Gmail Web app provides a consistent experience across platforms. Users don’t have to install anything or worry about syncing their email to multiple devices.
Figure 9.6. The Gmail Network app provides a consistent experience across platforms. Users don’t have to install thing or worry about syncing their email to multiple devices.

Gmail is also a great example of how creating good cross-platform user experiences can require a bunch of platform-specific optimizations. Although the Gmail app runs across upside and mobile chopines, there are actually several highly optimized versions of the app.

The Web as a platform itself, however, has few user experience consistencies of its personal. Although Network applications quota common features, there is no “Human Surface Guidelines” document for the internet (maybe there should be).[6] Or else, we focus on documenting good coding and design practices, such as progressive enhancement. Different browsers (that is, homegrown applications that run Web apps) implement the bahavior of core form controls differently. And that’s reason a Web application could behave differently in various browsers even if it has like net, components and code.

A browser is an application that runs in the context of the OS. In other words, a browser is a native application. A Web app, on the other hand, is an application that runs in the context of the browser. It is not a native application since it has one degree of separation (the browser) between it and the OS. Similarly, a Flash app runs in the context of a Web app. It is not a native Web application since it has one degree of separation (the Web app) between it and the browser. Flash apps, therefore, are not native to the browser, just as Web apps are not native to the OS. (Image: Rosmarie Voegtli,
Figure 9.7. A browser is an application that runs in the discourse of the OS. In other words, a browser is a native application. A Web app, on the another hand, is an application that runs in the context of the browser. It is not a native application since it has one measure of separation (the browser) between it and the PORTA. Similarly, a Flash app runs in the context of a Web app. It is not a native Network application since it has one degree of separation (the Trellis app) involving it and the browser. Shine apps, therefore, are not native to the browser, just as Web apps are not native to the OS. (Image: Rosmarie Voegtli,

Hybrid Applications

So, we’ve got native applications, which refer to the culture of the platform that they tear on, and we’ve got Web applications, which run in a browser on the Net. But we’ve missed a ordinal family that galore modern applications fall into: hybrid apps.

We need to comprehend the strengths of various technologies and use them where appropriate. Declarative Pattern authoring technologies (primarily HTML and CSS) are great for creating complex documents and styling them beautifully. Thus, many designers of original applications occupy HTML and CSS when they need to display rich content. These types of applications are called hybrid applications because they employ a mix of native and Web technologies.

The Facebook app on iPhone is a hybrid app
Figure 9.8. The Facebook app on iPhone is a hybrid app.

The Facebook app on iPhone is cardinal example of a interbred app, where certain sections (such as the news feed) are rendered using Web technologies.

Similarly, as we saw before, Web applications can also be crossed. A website authored in HTML, CSS and JavaScript and that uses Flash to display rich interactive content is an example of a hybrid Web application.

Many applications today are hybrids, and if you are accomplished in HTML, CSS and JavaScript, it is safe to say you will ne`er go hungry regardless of which platform or platforms end up becoming the utmost popular within the decades ahead.

Overcoming Ideological Leaning

Every too often, technology and design decisions are made based not on a desire to choose the best materials and tools for the job but on ideology. the internet standards suggest who blindly recommends the Web platform and Web authoring technologies for any project, regardless of the users’ needs is, unfortunately, all as well common. Developers who blindly advocate Flash and native iPhone or iPad apps all for any project are all too common, too. The old adage “When all you’ve is a cock, everything looks like a nail” comes to head. So, it is important to endorse such biases and to base your decisions on the needs of your users, not on ideology. It is also important to be able to recognize ideological views so that you can steer the discussion back into the realm of pattern.

Whatever recommends of Web standards hold a core assumption that the Web platform and Web authoring technologies are, by quality, a force for good. 1 wouldn’t quarrel that the Internet and, via extension, the Web have had element radical a democratizing effect on the world as the Gutenberg Grip (if not more so). Withal, the internet platform and authoring technologies are inherently neither good nor atrocious, and they could easily Be used for any end.

In the skin of the internet platform, the common assumption is that it is inherently good because any document or application placed next to it is universally accessible. While this may be true for open collections of documents — as was the norm for content in the premature days of the Web — it is generally not true for what we would consider a modern Web application today. Take Facebook. Facebook is a Web application. It isn’t open. It is free, but what this means is that you, the user, are not Facebook’s customer. You are Facebook’s product.[7]

Your in-person information and behavioral traits are what Facebook sells to its sincere clients, advertisers. Is this in any way inherently better or more than open than having to buy a commercial application from Apple’s App Bank?

Not really.

In reality, you could easily argue that buying a license for a commercial iPhone app is a more honest and outspoken transaction. You pay for it and thereby own a license to use it. You become the customer of the band or individual who made the application. There is transparency in how the company makes its money. In plentiful way, this is a much more traditional commercial relationship.

Of course, even commercial apps can use your data in devious ways, so being open-eyed about your personal information these days is important. But the point is that simply being a Web application does not somehow magically make it a force for good in the global.

Are Homegrown Applications and Platforms Endangered Taxon?

As Jeremy Keith famously put it astatine the Update Conference, “Writing a local app is like writing for LaserDisc.” The implication here is that native platforms, like CD-ROMs and LaserDiscs, will be obsolete soon since the Web is “catching up.”

I sure hope that is not the case, because the internet itself is a local podium and is becoming even more so (in the traditional sense) next to the come up of OS’s such as WebOS and Chromium, which are supported local Web authoring technologies. We’ve to understand that what the internet is supposedly catching up to is a moving target. New features, user experience enhancements and more are mortal added to native platforms all the time. It’s not like Apple will decide on 1 September 2012 that iOS is “done” and stop creating new versions of the OS or new models of iPhone and iPad, at which point the Web can lug a few years to finish catching up.

We know that “native” refers to the center culture and language of a level, so predicting the demise of “native” is analogous to saying that different devices will not have distinct cultures within the future.

The assumption real in this view is that a monoculture will arise in the future where every application on every device will speak via the components of the internet and be authored using native Web authoring technologies, and moreover that these applications will all be served from the Web platform. If anything, this is a greyish and chilling vision of the future, in which people will soul even less control of their own facts and where their tendency faculty only become dumb terminals that hook busy intense silos in the sky (“the cloud”) that are controlled by large corporations.

Instead of owning a license to a word-processing application, for occasion, you would write everything in Google Docs. Google, all for its part, will be analyzing every word and sentence, trying to comprehend more about who you are and what makes you tick so that it can use that information to better manipulate your commercial behavior.

This is not to say that Web applications are necessarily evil, just they are definitely not inherently good.

Blurring of the Lines

We keep hearing that “the Web is catching up to native.” What people mean when they read out this is that Web authoring technologies are feat better access to device features such as touch, hardware-accelerated graphics, GPS, accelerometer support and cameras. What is rarely mentioned, however, is how native applications are catching ahead to Web applications. Within some respects, the strides that native applications are making are far more important because they threaten the core user experience advantages that Web applications have historically enjoyed over native applications.

The 3 main areas in which endemic applications are catching up to Web applications are ease of deployment and access, automatic updates and seamless access to data.

Ease of Deployment and Access

One of the core user experience advantages that Object applications have historically had over native applications is the wellbeing with which they have the ability to be deployed and accessed. Click the “Upload” button within your FTP application of choice[8] and your app becomes accessible to anyone WHO has the URL anywhere within the world.[9] Simples.

No need to transfer a Zip file, then flush for an application to unfasten it with, then look for where you downloaded it to, next unzip it, past pose it, then run it, only to find out that it doesn’t support your graphics card. Eek! Is it any surprise that Web applications like Gmail and Google Docs have enjoyed such phenomenal success, especially on native platform beside insolvent usability?

The line between the user flows of Web applications and native OS applications is blurring. In fact, in OS’s based on Web technologies, Web applications are native OS applications.
Figure 9.9. The line between the user flows of Web applications and native OPENING applications is blurring. In fact, in OS’s based on Web technologies, Web applications are original OS applications.

However, native apps are catching up to the ease of deployment and accession offered by Web applications gratitude to the development of app stores. With an app store like Apple’s, the process of finding an application is as easy as hitting a URL in a browser. In certainty, you can hit a URL to reach an app in the App Store and, from there, simply click a button to download and install it.

Automatic Updates

Web applications, by spirit, have always provided automatic updates. In fact, we don’t even consider the “version” of a Net application because the Network is inherently version free.

You’re always using the latest copy of Gmail, and you don’t care what book it is.

It’s not Gmail 7; it’s just Gmail.[10]

Native applications, by contrast, have routinely had clunky update mechanisms that interrupt the user’s flow. That, too, is changing with increasingly native applications implementing seamless updates. When, for example, was the last juncture you noticed Google Chrome updating? Never. It does it softly.

Broadloom Access to Data

The various huge advantage that users of Web applications have traditionally enjoyed is the ability to access their notes from any device. You never have to worry about syncing email from your desktop to your mobile handset when using Gmail. It’s always at hand. Relate this to the nightmare that has traditionally plagued syncing connected native platforms.

Native apps, however, are again catching up. With Apple’s iCloud, all for instance, extremity synchronization is becoming a entry of the past. Your data is simply, transparently and automatically available on your Apple devices and is kept constantly in sync without your having to worry about it. Although iCloud is primarily an Apple-centric continuous punter solution, otherwise cross-platform technologies, such Dropbox, bring related advantages to other platforms.

Just Another Case

Did you read the previous partition thoroughly? Good. Then you may have noticed the common strand within all three areas where native applications are catching up to Web applications. They are all areas where the advantage in user experience is due to a characteristic of the Internet and not the internet . The Net is just a stack of technologies — namely, HTTP and URLs — on top of the Internet stack. So, local applications are catching up to the internet by taking advantage of the awfully same characteristics of the Internet that the internet does.

Furthermore, we are seeing the rise of a new type of human experience pattern, titled the continuous client. A continuous client experience — as originally planned by Joshua Topolsky[11] — lets a user seamlessly continue an experience across devices and contexts.

For example, if you are reading your Twitter stream on your computer and later seize your phone, you should be able to continue reading the stream from the same position. And when you get house, you should be competent to continue from the selfsame place again on your TV.

A good example of a continuous client in the wild is the Trillian instant-messaging application. It can store chats in the cloud, share chats between all of your devices within real instance, keep track of and synchronize your read and unread messages, and even make exercise of “presence technology” to know on which device you’re currently active so that it can send current notifications sole to that appliance.

Kelly Sommers has a nice sample app that showcases a continuous client experience: Users can start watching a video on their Windows Phone 7, continue in a Web client, and then on their iPhones.
Integer 9.10. Kelly Sommers has a pleasant sample app that showcases a continuous patron experience: Users can start watching a video on their Windows Phone 7, maintain in a Trellis client, and then on their iPhones.

If you think about it, in the age of continuous client experiences, the internet becomes JAC (just another client). It may be the best case to use in certain contexts, but users have the choice of switching to native clients without worrying about synchronizing data. Presently, continuous clie nts will be a core expectation instead of a novelty, particularly as high-level technologies, e.g. iCloud, make it easier for developers to implement them.

The instant messaging app Trillian is a good example of a continuous client. (Image: Trillian Blog,
Figure 9.11. The tick messaging app Trillian is a good example of a continuous case. (Image: Trillian Blog,

The Future is Native

the internet today is basically another native platform and one that, going forward, has to compete on its own peerless virtues and not on the advantages bestowed upon it by the web , because other native platforms are also implementing those same advantages.

The tricky question to answer when deciding whether to use the Web platform or other platforms for your next application is whether the power lies in exposing the user interface of your application as a native app or in exposing it via a URL and serving it via HTTP.

As Web applications attain to native platforms with features like Local Storage and the means to jog while the device is offline, the file betwixt Network and native applications blurs even added. This is taken to its logical extreme within OS’s like Palm’s WebOS and Google Chrome, where the native technologies are Trellis technologies.

We need to understand that a Web application running next to such an OS is a native application. At that point, our outcome is between different native OS’s and native frameworks. That choice will be greatly influenced by which native OS’s proffer a superior user experience. Subsequently, our technology choices will be between different original authoring technologies — HTML, CSS and JavaScript for domestic Web applications, Objective-C and Cocoa Touch all for native iOS apps, Island and Android SDK for Golem apps, C# and .NET for Windows Phone apps, and so on and so forth.

Regardless of which platforms and technologies win out in the close, the future is clearly native and the Web is JAC. Now, the billion-dollar question is not “Do we go Web Or native?” but rather “Which platform or platforms and which client technology or technologies should our new product support?”

To answer this, we need to comprehend the nature of our product and, specifically, where it falls on the documents-to-applications continuum.

The Documents-to-Applications Continuum

Against the Trellis, one way to classify products is according to whether they are content-centric or behavior-centric. We call a content-centric collection of documents a website. A behavior-centric product is called an application (or “app”). Instead of falling entirely in one camp or the other, your product faculty probably lie location between the two extremes on the documents-to-applications time.

The documents-to-applications continuum.
Figure 9.12. The documents-to-applications continuum.

When a product falls closer to the documents side of the continuum, we can finish progressive enhancement to layer features and interactions on top of the content-based core while keeping that core accessible to the largest amount of citizens possible. These progressively enhanced features usually either layer advanced formatting or design on these documents or add fanciful interactions all for navigating within Or linking them. We can make the content adapt to various screen sizes and make the limited interactions that are wont to navigate the content adapt to assorted sign mechanisms. This isn’t an easy task, but nor is it impossible.

As products change from the documents sideways of the spectrum to the applications side, even so, implementing progressive enhancement gets harder. Within fact, it might go all meaningless or impossible. How would you gracefully degrade an on the internet image editor, all for example? However would an image editor work against feature handsets without graphical displays? What content would you actually dribble back to displaying?

The principle of universality, as composed by the creator of the World Wide Web, Tim Berners-Lee, was written in an age when the Web was mostly a collection of interlinked documents. It doesn’t necessarily apply wholesale to applications, which have very different design constraints and requirements. See Lea Verou’s comment on John Allsopp’s retort to my one-version manifesto on .Net magazine:
Figure 9.13. The theory of universality, as composed by the creator of the World Wide Web, Tim Berners-Lee, was written within AN age once the Network was mostly a collection of interlinked documents. It doesn’t necessarily apply wholesale to applications, which hold very different logo constraints and requirements. See Lea Verou’s statement on John Allsopp’s retort to my one-version manifesto on .Net magazine:

Applications are not content-based; they’re behavior-based. Gracefully noxious to a simpler representation of some content an application might person does not e`er make sense. Applications are often made up all of behaviors that FTO users create content. Consider the image editor again: it doesn’t have any content itself, but it enables users to create content.

In order to create model user experiences, we need to maintain focus. This focus has to be settled squarely against meeting the needs of our users in the best way possible. No product team on Earth has the supplies to make up applications that provide the best possible user experience all for every someone.

Given unlimited time and supplies, we could optimize the user experience of our apps on top of every device and platform known to humankind. However, given limited time and budget we’ve to drudgery with in the real world, we essential be selective with our listeners, problem domain, platforms and tendency. We carry out this not to exclude people unnecessarily but because we realize that including each one and giving each one a great user experience is impractical.

Mobile Logo Considerations all for Document-Centric Products (Websites)

On the documents lateral of the continuum are websites. A website comprises content element well as the presentation of that content. The contented may be paper, images, audio, video, etc., that is marked up with HTML in order to add semantics and artefact. The presentation includes both the visual layout and the interactive elements (as navigation linking pages or states) and is as a rule implemented using a combination of CSS and JavaScript.

If you have a website, the first point you should do is test it out in mobile contexts to see how it displays and performs. I’ve encountered far too heaps companies that overlook the importance of making their websites mobile-friendly and jump straight into creating a native application. Be careful of devising this mistake, especially provided your website is an important revenue apparatus. All for document-centric websites, use progressive enhancement whenever possible to certify the blissful and core interactions for navigating and intense that content remain accessible to as wide a platform of your users arsenic getable.

To do so, you can follow these broad steps:

Ensure your content is accessible to everyone, and mark it up with proper semantics. Separating delighted from presentation is important.
Progressively enhance your happy to supply a more optimized experience for people display it at different screen sizes (this is the focus of responsive design currently).
Progressively raise your content to bring a more optimized experience for families of tendency based on supported features and capabilities (all for example, touch). In other libretto, make the website responsive in behavior, not just within plan. At this component, you are optimizing for features, not for specific devices (say, for all mobile phones that support touch, not just the iPhone).
Progressively enhance your content to support the novel culture and capabilities of the various devices you privation to support. At this point, optimizing for special devices is all right. There’s nothing wrong with trying to make the user experience as beautiful as feasible, even if it is all for a particular subset of your users halogen a time.

Make sure to test your designs on actual devices

A simulator or emulator is great for testing the effects of code changes while you’re developing, but they cannot recreate the creative ergonomics of the device itself. Context is also a key factor that affects the usability of mobile experiences, and a design that plant perfectly well below the exact lighting conditions of an office might not work as well in bright sunlight, for example.

Also, remember that when you test with a simulator, it uses your computer’s powerful hardware to race the application. You may well see slower performance—and even slightly different behavior—when running on an actual device.

Of programme, each of these steps will take time and more resources, and you will want to plan and budget accordingly. But what if making your current website responsive does not run into your users’ needs in this particular instance? Perhaps you need to provide a much optimized and focused experience than progressive enhancement allows given your budget and schedule, or perhaps you need a level of apparatus integration that is simply not getable through a browser currently? Here case, you might want to start reasoning about whether to build an app, and if so, if it will support multiple shoe and which technologies you should use to build it.

Cross-Platform or Solitary Platform?

Can you best group your users’ requests with an application that runs on multiple platforms or — At least initially — on a single level?

When answering this question, keep within mind that creating associate application for a single platform does not mean that you cannot create a separate app for a contrary platform later on. It just means that you will metal focusing your designing and development efforts on a single level (Or perhaps even a lone device) to start next to.

It also doesn’t , past itself, suggest whether you will metal creating an application that runs as a native binary or whether your application will use the native components of the device or devices that it runs on. (Using cross-platform authoring technologies to create an application that you’ve optimized for a one-woman platform is perfectly possible.)

The answer to this enquiry will, however, determine however much optimization you must do on varied platforms. If you work astir the user experience, you must optimize your app on all and every platform that you post. It will also feeling how much testing you must do (because you will need to test on every platform that you go to), the size of your support department (because you will need to troubleshoot user issues on top of every platform that you crutch), and how so much time and fund you need to set aside for these various functions.

The Myth of Write Once, Run Anywhere

A common mistake I see many designers make is to imagine that past using cross-platform authoring technologies they will be able to write once, run anyplace. This is a myth. And temporary on the myth can lead to rather expensive underestimations. Your application might run on triple platforms, but this rarely—if ever—means that it will run recovered on sevenfold platforms.

The only way to receive associate application to run all right on multiple platforms is to optimize it for each one of those platform and tendency. As mentioned earlier, every platform has its own culture, language and norms that users expect apps to conform to. And most users dont care how many other devices your application runs on — they trouble single active however well your application runs connected their appliance.

Designers who do not take the unique cultures, customs, dialect and norms of their respective platforms into consideration risk making their applications look and wholesome out of place. The applications will appear noticeably outside, unnecessarily loud and usually rather arrogant, simply because they are culturally insensitive.

Because we don’t want our applications to exhibit as obnoxious behavior, we must optimize them all for each platform we support. Our aim is to create applications that are culturally sensitive to the language, norms and custom of the platforms they talk . Thing less and we would Be showing varying degrees of disrespect to abiding segments of our users.

Demise with a M Cuts

The last thing you could act upon, course , is disrespect every of your users by creating a lowest-common-denominator application that gives every user on every pulpit an unoptimized human experience. At that point, you would be at your most vulnerable. Although your cross-platform application might have the possible to reach a large cipher of users because it runs on top of a large digit of devices and platforms, it will be at a disadvantage in user experience on every ane of those platforms. To put it bluntly, who cares if it runs on a faultless platform if it runs badly?

More importantly, what happens when a competitor comes by on i of those platforms with a beautifully planned, precisely optimized, delightful user experience and blows your app out of the water?

And then again by a different platform by a varied competitor?

This is death with a 1000 cuts, whereby your application is abandoned one platform at once for superior alternatives. Supporting multiple platforms isn’t a feature unless you can strut them all well. You may have first-to-market advantage, but that volition last lonesome until you’re outdone by your best-in-market competitor.

Write Once, Optimize Everywhere

So, write once, run anywhere is a dangerous story. Cross-platform applications that compete successfully are write once, perfect everywhere. You must understand the implications this will have on your fund and schedule and tactic for optimizing, testing and supporting your application on every platform you choose to support.

Please do not be taken in by the “create a cross-platform application in five minutes” demos by many tool vendors. They are rubbish, unless you’re building the simplest of to-do list apps. The true test of a development technology is not however easily it enables you to create a five-minute demo or how quickly it gets you 70% of the track to your goal, but rather how easily it enables you to tackle the last 30% of your development, including the all-important person experience optimizations that could take up the ending 10%. These inventory could end up winning up the majority of your time and endeavour in developing the application.

Web and Other Cross-Platform Technologies

Broadly speaking, cross-platform technologies can be split into two groups: those that create native binaries and those that don’t. We can also further categorize them as those that use native frameworks and those that don’t. The combination gives us the binary-framework matrix shown below:

The binary-framework matrix.
Figure 9.14. The binary-framework matrix.

A native binary is an application bundle that can be run directly by the OS of a given device. It is what we think of commonly when we refer to a “native app.”

Still, the far more key trial of nativeness is whether the application makes exhaust of native frameworks. These frameworks are what be the culture, language, gestures, symbols and norms of a platform.

External Apps Wrapped in Native Binaries (or Wolves in Sheep’s Garb)

Creating a native binary for iPhone that does not use any of the native components in the Drink Touch framework all for iOS is possible (and quite easy) by using a technology such as Adobe’s PhoneGap. PhoneGap wraps an existing Web application — that uses native Web components — and creates a native operating system application from it (in the example above, a native iOS application). While your app might look like a native app on the iPhone’s home surface and power launch like a native app, the UI of the app will be rendered using Web components.[12]

Your binary application is just a shell that contains a WebKit component. This WebKit component is what renders your Web application using Web components. Because Web components can’t meet native expectations, I would not recommend using PhoneGap to create non-immersive applications such as productivity apps.[13]

When grounds immersive applications such as eBooks and games, however, the demand of native framework support in similar technologies is not as capacious a problem. Adobe Shine and ActionScript, Unity and Ansca’s Corona are favorites among native game and eBook app makers, even though they do not utilize native frameworks whether components. This is because immersive apps rarely, if ever, use domestic components. Instead, their designers aim to create a completely different world — perhaps a skeuomorphic cardinal that looks and behaves like a real-world book — near its own rules, interactions and culture.

I do not recommend Clay Flex (or applications that use components from the Flash framework) for the same reason that I dont recommend using PhoneGap to fabricate non-immersive native applications: they do not adapt to the culture of the native dais and will do differently than native components on the system.

Within summary, metal careful when creating endemic binaries that simply wrap applications that do not use native components. These apps have a tendency to resemble native applications, but they cannot act like native applications because they don’t activity native components in native frameworks. A PhoneGap application that uses the jQTouch framework might showing what looks like an iOS table view when running on an iPhone, but this is simply an HTML look similar brought to life by bright use of CSS and JavaScript. It pretends to be an iOS table view, but it cannot meet the behavioral characteristics of a real table view component from the Cocoa Touch framework, and gum it ends up creating expectations that it cannot meet.[14]

Creating unmet expectations is a highest faux pas of usability. Avoid it like the plague.

Immersive vs. Non-Immersive Applications

Understanding the distinction between immersive and non-immersive applications is important because the nativeness of an application is substantially less of an issue all for immersive applications.

Immersive applications usually arrogate the whole device and, by definition, create their personal culture and language. A good example is games. A game could have its own control system for moving, jumping and attack. Far from conforming to the culture of the platform, a good game transports the person to a world of its own creation. As such as, immersive applications usually employ few, if any, of the platform’s conventions. Per se , they are prime candidates for the use of non-native technologies.

This explains why Flash, time not native to the internet , is such a popular technology for delivering immersive experiences such as games connected the internet ; or why Unity, while not using the native components in Cocoa Touch, is used to make many of the top games on iOS and other chopines.

Non-immersive applications (such arsenic productivity apps) usually bring in heavy use of standard user-interface elements like buttons and table views. They use platform-specific interactions like full-screen “master-detail” transitions on top of iOS, whereas they might use a tree-view evenness on a Windows or OS X application. It is thus very important that non-immersive applications speak the native terms and conform to the native society and norms of the platforms they dash on.

All that being said, even for immersive applications, performance could still be an cause that influences your choice of whether to use native or non-native technologies. Certain games — such As first-person shooters — need to squeeze equally of performance out of a system in order to shine. In these situations, some non-native technologies might not be performant enough all for your wishes. The early versions of Adobe AIR-based Flash apps on iPhone, for example, were notoriously slow. Adobe has built performance in the latest versions of Adobe AIR on iOS, though.

Native Apps Translated From Non-Native Languages

If your goal is to provide an optimized user experience, a better cross-platform approach when creating non-immersive native applications would be to operation native frameworks and components. This does not necessarily mean that you have to use the native programming language for a given platform to author your application.

Using Appcelerator’s Titanium Mobile SDK, for example, you could write JavaScript to instantiate and populate native components.[15] Thus, on iOS, once you create a table view in Titanium Mobile, a native Cocoa Touch table view component (a UI TableView case) is created in your user interface. This not lone looks like a native table view (as could likewise be the case in a PhoneGap application that mimics the native components) but certainly is a native table view. Record importantly, it behaves As a table view should.

The exhaust of a scripting language like JavaScript can spawn it easier to author applications and reuse your team’s existing Web development skills, while still affording you all of the advantages of using native components within your original applications.

Also, because Titanium Mobile is a cross-platform technology, it knows to instantiate native iOS components for your native iOS app and use native Android components or else when compiling your native Automaton app. The advantages are clear: you use a single scripting language (JavaScript) and have to maintain just one code base, instead of having to learn and use Objective-C on top of iOS and Java on Android and maintain two separate code bases.

The disadvantage is that you have yet another layer of abstraction to drudgery with. Ultimately, the quality of your applications faculty depend by the quality of the code that Appcelerator writes within its abstraction frameworks. And you will be parasitic on top of how swiftly Appcelerator supports new features that are released to the native frameworks and SDKs. Though Appcelerator tries to generate the differences between platforms as transparent as thinkable in Titanium, there are differences — not least of all cultural ones — that you will still need to address and hone for (remember that our credo is write once, optimize everywhere).

Comparison of some common native and cross-platform technologies.
Figure 9.15. Comparison of some joint domestic and cross-platform technologies.

Native isn’t necessarily better, but it is native.

The only way to create applications that conform to the norms — that is, the nation and language — of a given platform is to use native technologies. E.g., spell creating Brassy applications that are served next to the Web platform is possible, they’ll not look or feel like native Web applications that use local Web authoring technologies like HTML, CSS and JavaScript. Similarly, patch using these technologies to create applications for platforms like the iPhone is possible, the applications will not exterior or surface like native iPhone applications that are created using the components in the Cocoa Touch framework. That isn’t to say that Flash applications cannot perform recovered than HTML applications. In certain use cases — especially immersive apps suchlike games — Flash applications might provide a better user experience. Machinarium, all for instance, is a lovely game created within Tatty that runs beautifully on iPad. Once more, especially for immersive applications suchlike games and eBooks, a cross-platform technology like Unity OR Corona could reduce development time and survive easier to implement features that would be more difficult to create using native technologies (specified as a 3-D surroundings or a physics engine).

Machinarium on iPad, an immersive native app created in Flash.
Figure 9.16. Machinarium on iPad, an immersive native app created in Flash.

This is not to say that you should fear cross-platform technologies, but rather that you should do your research, measure the pros and cons and make an informed verdict of whether to add different layer of abstraction to your development process. All cross-platform technology has different advantages and disadvantages and fritter cases that make it a better fit for certain types of applications. Patch Halo might be the perfect choice for a 2-D physics-based game, Titanium Mobile might be better for building a cross-platform productivity application.

Of course, Titanium is not the solitary cross-platform technology that can create native binaries and use homegrown frameworks. If your team has skills within C# and .NET development, you might also want to reckon Mono (and specifically MonoTouch for iOS and Mono for Android). Mono works in much the selfsame way As Titanium, only instead of using JavaScript, you use the C# programming words (… and, with caveats, another .NET programming languages) and .NET patterns and tools to write native apps.

Web Applications

If you’re reading this book, you are probably either a Web engineer or a Web developer (or both), or you are learning to become one. Your role as a Web designer might involve anything from designing collections of documents (in which casing you would rely heavily on your graphic design skills) to designing behavior-rich applications (in which case you would glucinium exercising your interaction design skills).

You likewise have a rich selection of materials to determine from when scheming your products. Depending connected the needs of your audience, you might choose to exploit native Web authoring technologies such as HTML, CSS and JavaScript to write native Web applications; alternatively, you may well exploit non-native cross-platform application authoring technologies such as Adobe Flash or Wholeness to create non-native Web applications. Arsenic a third option, you might use a combination of some native and non-native authoring technologies to create hybrid Web applications — for example, a website improved primarily next to HTML, CSS and JavaScript but complemented with Flash to deliver a rich gaming experience.

Regardless of your choice of local or non-native Net technologies, what makes a Web application a Web application is that it is deployed to, and accessed from, the World Statewide Web platform. This means, at its simplest, that your website or application has a URL[16] and is served via HTTP.

Single-Platform Native Applications

Having worked through the method above, you might decide that you would best serve the needs of your users by tackling a single platform or device for your application and investing your limited incident and budget into optimizing the user experience all for that platform.

Whether you do decide to support a single platform, you still have technology choices to make. If you’re making a game or opposite immersive application, you can choose a cross-platform technology that is specifically geared to making it easy to critic such applications, specified As Ansca’s Corona, Unity or Adobe Tasteless.

If you are building a non-immersive application, you still have the option of using a cross platform toolset like Titanium Mobile or Mono. The downside there is that your development process volition involve ane additional translation layer, and you shall mortal less control over optimizing the performance of the application because you will be reliant to some degree next to the native opinion that Titanium’s engineers mortal written. Even if you perform use Titanium (or a siamese framework like Mono), remember that you faculty unmoving soul to learn the native frameworks (or Apis) of the platform that you are developing for. Learning new frameworks is so much harder than learning new programming languages. Whereas a seasoned programmer could pick up a programming language like Objective-C in a matter of days, it could take weeks (except months or years) for a developer to full grok and become comfortable with the patterns, culture and intricacies of a bodywork like Cocoa Touch.

Finally, you could use the native toolset of your platform of choice. All for example, you can squander Xcode with Objective-C and Cocoa Contact to build a native iOS application, or Eclipse beside the Automaton SDK to build a homegrown Android application, or Visual Work beside C# and the .NET framework to build a Windows Phone application.

This could involve learning a topical programming language (Objective-C for iOS, Java all for Android and C# for Windows Phone) or hiring troop members who know the language and have experience with the native framework. As stated, picking up a new language is easy, but learning a trial framework is much harder. Keep that in mind when deciding whether to go this route if you or your team do not already possess the requisite skills.

The advantages of building native applications using native technologies are numerous. For one thing, you have complete flexibility in optimizing the application and user experience. When you use domestic components and adhere to the human interface guidelines for your chosen podium, your application will conform to the culture, language and norms of that platform. It volition be easier for users to memorize and use. Also, since you’re not reliant on a foreign abstraction or translation layer, you’ll always be working with the latest code and frameworks from the manufacturer, bounteous you additional flexibility to accommodate clean features and updates as they are released for the platform. Most importantly, concentrating your efforts on a single platform means that you can put the time that you would otherwise have spent optimizing, testing and supporting other platforms into refining and optimizing the user experience of your application first, and if necessary add support to variant platforms ulterior on.

Scheming for Group

The platforms and technologies that you decide to use for your next product will have a essential impact on how the goods is accessed, how it looks and feels, and whether it meets—and hopefully exceeds—the requests of your users. This isn’t a decision to be taken lightly or brushed over.

If your choice of platforms and technologies is based simply next to your perceived short-term business needs or on the current competencies of your team, then you’re making a decision that solves your own problems, not the user’s problems. This may have short-term advantages, simply you will not be able to compete within the long term next to those who solve the user’s problems first. Your choice of technologies and shoe should be based on how best you can meet the user’s wishes, not next to ideological bias or on obtaining short-term gain at the risk of long-term loss.

Remember that there are already too many things out there. We don’t need more property. We need things that work better. Make things that advise, empower and hearten. And implement the right tools and technologies for the errand.


[1] To learn more about working this way, read up on agile methodologies and user-centered product development. The merging of these two worlds &mdash that is, adding sufficient design and user testing to every iteration in an agile process &mdash is what I named user-centered active product development back in 2003:

[2] These norms are usually expressed in interface guidelines for the platforms, as the human interface guidelines that exist for the Mac, iPhone, iPad and Android platforms. (Android is the odd one out here since it is not really a single platform but has many flavors, each customized by device manufactures and mobile carriers. This is why it is very difficult for Google to exercise control over the user experience of the Android platform. Good user experience is a operate of control — and Google has very little control over the user experience of phones based on the Android platform.

[6] Seat Tantek Çelik’s call all for “Web Human Interface Guidelines” ( and read Joe Hewitt’s post career for more focus and vision for Web technologies (

[7] As Saint Lewis states, “If you are not paying for it, you’re not the customer; you’re the commodity being sold.”,

[8] Or, if you’re truly savvy and use a Git repository, you could expend a post-commit catch to automatically deploy your current commit to the waiter.

[9] Leastways where the URL isn’t blocked by an autocratic regime.

[10] Read au fait the “one version manifesto” and the versionless part of the Web in my opinion piece within .Lattice magazine titled “My Websites Will Only Sustain the Latest Browser Versions”:

[11] Topolsky, Joshua. “A modest proposal: the Continuous Client,”

[12] PhoneGap does not dictate the use of any particular Web UI model (for example, jQuery Open). All it does is let you wrap a Object application in a native application. However, regardless of which UI framework you use (or even if you decide not to use a Web UI framework at all), the rendered components faculty be Web UI components, not the native UI components of the platform that your app runs on.

[13] The said can metal said for Web applications that are added to the residence screens of phones. Again, the Web application in probe looks like a native app, launches like a homegrown app, just does not act like a native app. A Net application running within the browser does not have these shortcomings because it does not create the expectations of a native OS app within the first place. A Web application moving in the spectator is a native Web application, and native Web applications — just similar native apps on other platforms — have their own culture, conventions, language, norms and expectations (even though these might not be as strongly defined as on some other native platforms).

[14] The biggest usability false pas you can commit is to style or skin non-native components to be like native components (as the jQTouch framework does). Whereas components in a native app that do not look like native components leastways offer a visual clue that they will probably not behave like endemic components, non-native components that act as if to be native components will confuse users even more by appearing a absolute way but behaving differently. The superior thing to do, logically , is to use homegrown components in your native apps. Failing that, at lowest make your components different enough visually truthful that you do not create behavioral expectations that you can not meet.

[15] Don’t confuse Ti Mobile with Titanium Desktop. The latter works just like PhoneGap. Appcelerator has lately open-sourced Titanium Desktop (now called Desktop) and is focusing its efforts on improving Titanium Mobile:

[16] More precisely known as a URI, even though there are technical differences between the two that would make a W3C standards geek crust at the mouth provided they were to see as casual a dismissal of those differences as is being displayed present.

Download the stuffed variation of the chapter all for free!

You can download this section within various formats:

download the chapter in PDF (2.64 Mb),
download the chapter in ePUB (1.59 Mb),
download the section within Mobipocket (Kindle) (2.02 Mb) whether
download the chapter’s .zip with all formats (10.55 Mb).

We’d sincerely appreciate your advocate beside an occasional tweet, Facebook post—or just spread the word to your friends and colleagues. You can also learn more about the Smashing Book #3 prime. Once more, convey you for every your support!

Smashing Books #3

© Aral Balkan for Smashing Mag, 2012.


  1. #1 by webdevelopmentwebsite on July 4, 2012 - 5:23 am

    06/20/12 – Manage your mail server configuring its features to your stipulations.Date:

  2. #2 by webdevelopmentwebsite on July 4, 2012 - 10:00 am


    There is no doubt about it, I am a hypocrite. Fortunately nobody has noticed… up to now . Here’s the thing. On one hand I talk about the importance of having a good work/life balance, and yet on the other I prefer to hire people who party personal projects in their spare time.
    Complete you seat the conundrum with this scenario? How can one person perhaps juggle work, life and the odd side task? It would appear there just aren’t ample hours in the day. Being the arrogant and stubborn individual I am, when this hypocrisy was pointed out to ME, my immediate reaction was to endeavour to justify my position. A less opinionated individual would probably have selected one or the variant, but I propose these two supposedly contradictory viewpoints can sit out harmoniously together.
    Can you have your cake and eat it, by working on squad projects, retaining feathers a job and still having a life beyond your computer? Image with GuySie.
    To understand however this is possible we must first establish why a work/life balance is important and what role side projects play. Let’s begin via asking ourselves why it is important to have a life past our computers, even when we love what we do.
    Ground We Should Have A Life Out of The Web
    Generally speaking Web designers love their errand. In many cases our job is also our by-line. We love nothing more experimenting with new technology and techniques. Once we aren’t working on websites we are tinkering with gadgets and spending a much complex than average case online. Although in our job this single-mindedness is effective, it is ultimately damaging both for our personal safety and career.
    In the early life of my career, when I was infantile, I used to happily hard work long hours and regularly pull all-nighters. It was fun and I enjoyed my job. However, this set a habit in my working life that perpetual far longer than was sound. Eventually I became stressed and vicious ill. Within the end holding became so bad that I was completely unproductive.
    This high-intensity working also sets a standard all for the whole industry, wherever it becomes the norm to work at this accelerated hurry. No longer are we practical long hours because we want to, but rather because there is an expectation we should. This kind of work/life balance can sole downfall one way, in burnout. This indemnity us personally, our clients and the industry as a whole. It is in our own interest and those of our clients to face after our health.
    This means we can not spend our lives sitting in front of a screen. It simply isn’t wholesome. Instead we need to participate in activities past our desks. Preferably activities that involve astatine tiniest some exercise. A healthy fare wouldn’t hurt either. Getting out the internet (and Pattern community) offers another benefits too. It is an opportunity for us to interact with non Web people. Whether you are helping a charity or joining a rock climbing club, the people you meet module provide a much more realistic view of how ‘normal’ people lead their lives.
    This will inform our drudgery. I often think that, element Trellis designers, we sleep in a bubble in which each one is on twitter all daytime, and comprehends that writing a URL into Google isn’t the longest way to get a website. Not that this is all we volition learn from others. We can also acquire from another people’s jobs. For paradigm, there is a group we can learn from architects, psychologists, marketeers and uncounted other professions. We can swot up from their processes, techniques, dexterity and mentality. All of this can be applied to our relevant role.
    As mortal who attends a religion (with a reasonable mix section of people) and used to run a youth group, I can attest that mixing beside non Web family module modify your view of what we bash. Furthermore, the activities you undertake will contour how you carry out work. Language a non-Web book, guest associate art gallery, or even taking a walk in the countryside, can all inform and inspire your Web work. There is probably , that stepping out the computer element the end of a working day will benefit you personally and professionally. Does this therefore mean you should shelve your side projects? Not at all, these are just as important.
    Why We Should All Have Side Projects
    I love to hire people who own side projects. Take for example Rob Borley who works at Headscape. He runs a takeaway ordering site, has his own mobile app business and has just launched an iPad app. These projects enjoy been greatly beneficial to Headscape. Rob has become our mobile skilful, has a good touch on what it takes to motorboat a successful Net app and puts his entrepreneurial enthusiasm into everything he does for us.
    Rob’s side projects such as iTakeout has broadened his experience and made him an indispensable employee.
    Only side projects don’t rightful benefit your employer, they help your personal career. They furnish you beside a chance to experiment and learn new techniques that your day line might not allow. They likewise provide you with the chance to widen your skills into new areas and roles. Perhaps in your day job you are a engineer, but your sidelong project might offer the perfect opportunity to learn some PHP. To finish, side projects allow you to work without constraints. This is thing lots of us crave and being able to set our own agenda is freeing. However, it is also a challenge. We ought learn how to present when there is nobody sitting over our shoulder pushing us to launch.
    Every of this knowledge from personal projects has a transformative effect that will change your career. It will increase your occasion of getting a errand and show your employer how valuable you are. It may also convince your employer to create a errand that superior utilises your skills, as we did for Loot. Rob used to be a project manager, but once we saw his passion and knowledge for animated we created a new role focusing on that. Of course, this leads us to the obvious question: how can we someone time away from the computer if we should also beryllium working on side projects?
    Is Hustling The Statement?
    Provided you listen in to Gary Vaynerchuk or read Jason Calacanis, you maybe forgiven for thinking the answer is to ‘hustle’; to work harder. They proclaim we should cut out TV, dump the xbox and focus single-mindedly by achieving our goals. There is certainly a grain of reality in this. We often fritter away huge amounts of time, largely unaware of where it is going. We need to be much much conscious about however we are spending our time and ensure we are making a choice about where it goes.
    I don’t think valid harder is the long term solution, however. We have the ability to work hard for short periods of time, but as we have already established this can’t continue indefinitely. We need downtime. We need time lounging in front of the TV Or mindlessly shooting our friends in Halo. Provided we don’t person that we ne`er allow our brain the opportunity to recuperate and we finale up undermining our efficiency. I don’t believe the statement is “work hard, comedy hard”. I reflect the answer is “work smarter”.
    We Can Apply Everything If We Work Smarter
    Working smarter is about three things:

    Combining interests,
    Creating structure,
    Knowing yourself.

    Let’s gaze at all in turn.
    Harvester Interests
    A good starting factor when it comes to working smarter is to look all for commonality linking the three aspects of your life (carry out, life and side projects). You can normally achieve a lot by coming up with things that have a positive impact in each of those areas. Take all for example the choice of your personal project. If you look at most personal projects retired there, they’re aimed at a technical audience. We are encouraged to “build for people similar us” which has led to an eternal plethora of HTML frameworks and WordPress plugins.
    Maybe if we got out more there would be a wider range of personal projects and fewer of near identical jQuery plugins!
    If withal we have built up interests outside of the Web, suddenly it opens up a new world of possibilities all for side projects.
    I sought to get to know more people at my church. There are so many I have never spoken to. I also wanted to keep my hand within with belief (as I don’t get to code a deal anymore), so I decided to build a new church website in my spare time. This neck-deep talking to lots of people from the minster, and also gave Maine the occasion to experiment near recent way of coding. What is more, some of the things I learned human been valuable at work too.
    Look for ways of combining personal projects with outside activities. Alternatively, place players projects that could make your working life easier. This kind of crossover lets you get more done. However, by itself that is not enough. We need some structure too.
    Create Structure
    If we want to get the balance correct between personal projects, work and life we want a few structure to work in.
    All for a start take control of your method hours. I cognize this isn’t jammy whether you mortal a slave driver of a company, but most of us have at smallest some control over how perennial we work. You faculty be surprised, limiting your hours won’t injury your productivity as much as you think. You will probably get As much done within less time. Work tends to expand to take as much time as you are willing to give it. Adjacent, stop fluttering from cardinal thing to another. When you are “having a life” don’t check activity email or answer calls. Within is a budding expectation we should be available 24/7. Resist it.
    One method to maintain you focused is the Pomodoro technique. This simplex approach breaks your year into a series of 30 minute chunks. You work for 25 minutes by a singular task free from interruption and next have a 5 small break. Akin tasks are grouped together so that you spend 25 report answering e-mail rather than allowing email to interupt other blocks of career.
    The Pomodoro technique is a simple way of staying focus on the task within hand.
    Set specific time for valid on top of personal projects and stick them. Don’t let that juncture to increase into your exonerate time. As don’t allow slog to distract you from your side work. Set boundaries. If you need to, set an dismay for each activity. Nada will focus your mind on a personal project like having only 30 minutes until your fright goes off. You will inevitably try and squeeze just one more object in. These artificial deadlines can be very motivating.
    At length, make confident work, private projects and recreation all have equal priority in your mind. One way to party this is to spending a task manager close to Omnifocus, Things or Wunderlist to keep each your tasks within one place. Ofttimes we’ve a errand list for our work only not for other aspects of our life. This means that work is always prioritised over other activities. It is meet as important to have a task to “finish that book” you are reading as “debug IE7”. Providing edifice won’t just help with your line-up projects. It will also help with your sanity.
    Know Yourself
    Retrieve, the goal here’s to have fun on side projects, broaden your horizon with outside activities and recharge with downtime. You therefore must be vigilant in keeping the balance and assure that all these enemy priorities don’t drain you.
    Part of the riddle is that we spend de trop time on activities that we are just not fit to. Its important to recognize your weaknesses and avoid them. If you don’t, you excess time doing things you hate and doing them badly. For example, I just am no good element DIY. I used to dissipate hours wearisome to put up shelves and assemble utility. Because I was trying to do thing I was pale element, it would take forever and leave me too fatigued to do other property.
    My solution to this question was to delegate. I employed people to do my DIY. People that could do it much quicker and to a higher quality than Maine. However did I pay for this? I did what I was good at, building websites. I would pursue by the abnormal freelance site, which I could turn around quickly and enjoy doing. This applies to the players projects we approve overly. Learning new skills is one thing, but if it stops being fun because you are just not suitable to it, go on . Working on stuff you are not suited to will just leave you demoralized and tired.
    Talking of being tired, I would recommend not in use on personal projects immediately after effort home from work. Give yourself event to unwind and grant your brain to rest. Every bit don’t work on top of side projects justified up until you go to bed. This will romp havoc near your nod off patterns and threaten your productivity.
    Finally, remember that side projects are meant to be fun. Don’t undertake thing too large because not seeing regular grades will weaken your enthusiasm. If you want to hard work on something roomy, I suggest working next to others. Nearby is certainly no shortage of opportunities. Alternatively try breaking up the project into smaller sub-projects each with a functioning deliverable.
    Am I Asking For The Impossible?
    So there you have it. My attempt to have my cake and eat it. I believe you can have side projects, a life beyond computers and get the day job done. It’s not e`er easy and if I had to pick I would choose having a life over players projects. However, I suppose that personal projects can metal fun, good for our careers and also facilitate a duration beyond the Web.
    Hence do you agree? Am I being unrealistic? What challenges do you find in striking the balance or what advice do you have for others? These are just my thoughts and I am sure you can add a lot to the discussion within the comments.

    © Paul Boag all for Groovy Magazine, 2012.Date: 2012-06-19T12:34:59Z

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: