Archive

Archive for October, 2014

Icons Of Digital Design

October 3rd, 2014 No comments
GI_Wim-Crouwel_New-Alphabet-opt

Apple launched the Macintosh personal computer in 1984. It was more user-friendly than other PCs at that time — and, with its desktop publishing software, graphical user interface and mouse (all novel at the time), the Mac was uniquely geared to designers. Compared to what we can create on the computer today, the original Macintosh, with only 128 KB of memory, had limited capabilities. At the time, though, it opened up so many new possibilities.

Of course, using a computer didn’t automatically make designers better at their craft. Instead, the new technology gave them more control and sped up their exploration process. As with anything unfamiliar, the Mac sparked debate among designers during this time: While some saw the computer as simply another tool for creating work, like a drawing pen, others saw its potential as a medium in itself.

Emerging digital technology also changed typography, exploding the number of typefaces available and giving designers the tools to create and distribute their own fonts. Some digital typefaces were updated versions of classics, while others were brand new: type that was made for low-resolution screens, and type that was less functional and more illustrative. It was easier to break the rules. There was a refreshing jolt of youthful experimentation as people moved past the limits of the rational and functional.

I wrote my book Graphic Icons: Visionaries Who Shaped Modern Graphic Design to highlight the era’s influential designers, from El Lissitzky in the early 1900s to Stefan Sagmeister today. Each of these designers broke from tradition and changed the world of design in some way. Those who designed not only on the screen, but for the screen, ushered in a new era of digital design, mixing media and incorporating motion, sound and interactivity. Below are a few of those pioneers.

Wim Crouwel

First, though, let’s step back. Twenty years before the Macintosh was released, Dutch designer Wim Crouwel1 had an uncanny sense of how computers would influence design and vice versa. In the 1960s, developments in printing technology gave designers more control over their work: Instead of relying on a printer to compose type and position images in a layout, designers used rub-down type and photomechanical transfer to do it themselves. This DIY approach gave designers more freedom and flexibility in using, manipulating and creating type.

New alphabet, 1967

The computer was in its early stages at the time, and Crouwel saw an exhibition in Germany on digital type production. The limitations were clear to him. Dot-matrix printers and computer screens couldn’t reproduce traditional type with curved letterforms. So, he created a groundbreaking typeface to work with this emerging technology.

Starting with the Swiss typographic grid, Crouwel based letters on the rectangle, using only vertical, horizontal and diagonal lines. The result was 1967’s New Alphabet, so radical in appearance that it was almost abstract. It was never meant to be used; it was just an experiment. Crouwel must have been surprised to see the New Alphabet used on the cover that Peter Saville designed for New Order’s Substance album 20 years later.

Still, that concept influenced his future work, like his poster for Vormgevers (“Designers”), for which he hand-rendered the lettering based on squares in a visible grid. Crouwel developed a system for Amsterdam’s Stedelijk Museum where each piece — posters, brochures, advertisements — used the same grid. Although these pieces promoted art exhibits, they never depicted the art itself. The type-centric design and common grid unified the museum’s communications, yet the system was flexible enough to remain fresh and interesting.

GI_Wim-Crouwel_Vormgevers-opt
Vormgevers poster, 1968, for the Stedelijk Museum

Crouwel also broke new ground in how Dutch designers worked. In the 1960s, Dutch companies with large projects often hired larger firms in cities like London, thinking that the local designers who usually worked solo wouldn’t be able to handle the workload. In order to attract those large projects, Crouwel and four partners, with a range of experience in graphic and industrial design, formed Total Design. It was the country’s first multidisciplinary studio, where teams handled complex two- and three-dimensional projects. It was successful: Private corporations, government agencies and arts organizations hired Total, and their designs for postage stamps, airport signage and museum posters made a distinct mark on the country’s visual culture.

GI_Wim-Crouwel_Leger-opt
Leger poster, 1957

Hans Rudi Erdt, A.M. Cassandre and especially Josef Müller-Brockmann2 are big influences on Crouwel’s work, and in turn, Crouwel remains a prevalent figure in the design world — in 2013, he was celebrated with a retrospective at London’s Design Museum3. Crouwel inspires young designers, including Philippe Apeloig and Spin, who created a series of posters based on the grid he developed for the Stedelijk Museum.

GI_Wim-Crouwel_Calendar-opt
Calendar, 1964

April Greiman

April Greiman4 uses different words to describe what she does: “hybrid imagery,” “transmedia,” “visual communication.” But not “graphic design.” She feels that term refers exclusively to print, and her work combines elements from different types of media. Greiman thinks in terms of space when she designs, not in terms of a page. This is probably why designing digitally has been such a good fit for her.

GI_Greiman_YourTurnMyTurn-opt
Your Turn My Turn 3-D poster, 1983

New Wave typographer Wolfgang Weingart5 encouraged Greiman, while she was in graduate school at Basel in the early 1970s, to break free from a grid-based approach to design — to layer type, and to float it in space. She brought this knowledge to New York; and, after growing frustrated by the rigid limitations imposed by East Coast clients, she moved in 1976 to Los Angeles and opened a studio. The change of location opened her eyes and encouraged her to explore. She began teaching at the California Institute of the Arts (CalArts) in 1982 and gained access to the school’s computers and video equipment.

The new technology opened so many possibilities for Greiman, enabling her to combine print, video and type into multiple layers that were previously impossible to create. She felt strongly that these new tools weren’t just a means to arrive at the same old solutions, but that they should lead us to explore ideas and create something new.

GI_Greiman_Does-it-make-sense-opt
“Does it Make Sense?” in Design Quarterly, 1986

When Greiman designed an issue of Design Quarterly for the Walker Art Center in 1986, she blew up the traditional magazine format, creating a 2 × 6-foot folding collage that combined a nude portrait of the designer overlaid with multiple layers of images and text. While the fact that Greiman used a computer to create the work hardly seems noteworthy today, consider that the computer had one megabyte of RAM and a monochrome 9-inch display.

Greiman built the collage on the computer and outputted letter-sized pages on her dot-matrix machine, then directed the magazine’s printer to assemble the pages and photograph the entire composition. Greiman wasn’t just tinkering with the computer; she was exploring the idea of making sense, touching on philosophy and physics. Like much of Greiman’s work, the project wasn’t just about technology, but was personal.

GI_Greiman_19thAmendmenStamp-opt
19th Amendment commemorative stamp, US Postal Service, 1995

Greiman’s list of influences is well-rounded: Among them are her former teachers Armin Hofmann6 and Wolfgang Weingart; singer, songwriter and poet Leonard Cohen; theoretical physicist David Bohm; psychiatrist Carl Jung; and spiritual leader the Dalai Lama.

GI_Greiman_HandHoldingBowlofRice-opt
“Hand Holding a Bowl of Rice” mural, Wilshire Vermont Station, Los Angeles, 2007

As the world continues to change, so does Greiman. More recently, she’s been creating web design, branding, signage and public art and has been consulting on color, finishes and textures for architectural projects. She continues to teach and believes in always being open to new ways of doing things.

Do what you love to do, with a vengeance. It’s not what you do but who you are.

– April Greiman

Muriel Cooper

Muriel Cooper had two design careers: first as a print designer and secondly as a groundbreaking digital designer. Both revolved around the Massachusetts Institute of Technology (MIT), and both were based on her quest to make static media more dynamic.

MIT’s Office of Publications hired Cooper in 1952 and continued working with her after she established her own studio. She then became art director for MIT Press, where she designed classic books, such as Hans Wingler’s Bauhaus7. She designed the first edition of Learning From Las Vegas; authors Robert Venturi, Denise Scott Brown and Steven Izenour hated what she did, but many graphic designers loved it. She also designed the abstract logo for MIT Press, a modern classic.

GI_Cooper_MITPressLogo-opt
MIT Press logo

Cooper took her first computer class at MIT in 1967, and it bewildered her. However, she could see the computer’s potential in the creative process and soon began the second phase of her career: applying her design skills to computer screens. With Ron MacNeil, Cooper cofounded the research group Visible Language Workshop in 1975, which later became part of MIT’s Media Lab8. Cooper didn’t write code; she was the designer and the thinker. She knew what she wanted visually and encouraged her students to use technology to present well-designed information.

GI_Cooper_VLW_01_Media-opt
Image rendered as soft type, MIT Media Lab’s Visible Language Workshop

Cooper presented the group’s research9 at the influential TED5 (Technology, Entertainment, Design) conference in 1994. For the first time, computer graphics were shown in three transparent dimensions, which moved, changed sizes and shifted focus, instead of the standard Microsoft Windows interface of opaque panels stacked like cards. She made a big impact: Even Microsoft founder Bill Gates was interested in her work. Unfortunately, she died soon after of a heart attack, but her legacy in interactive design continues.

Muriel Cooper taught me that design had very little to do with how you make something, and instead why you make something.

– John Maeda

GI_Cooper_VLW_02_1994-opt
“Information Landscape,” MIT Media Lab’s Visible Language Workshop, 1994

Rudy VanderLans And Zuzana Licko

Apple broke new ground when it introduced the Macintosh computer in 1984. Designers Rudy VanderLans and Zuzana Licko did the same (albeit on a smaller scale) with Emigre10 magazine that same year.

While many designers initially resisted the computer, VanderLans and Licko embraced it, though in different and complementary ways: VanderLans liked the freedom it gave him in designing layouts, while Licko found a disciplined method for designing type.

GI_Emigre_19Cover-opt
Emigre magazine cover, number 19

VanderLans studied design in The Netherlands and worked at Wim Crouwel’s Total Design. But he was more attracted to the expressive work of Herb Lubalin11 and Milton Glaser12 than to the Dutch modernists. He went on to study photography at UC Berkeley, where he met Licko, his future wife and business partner, as she studied graphic communications.

Emigre magazine quickly became a forum for designers, especially those interested in experimentation and technology. It featured in-depth articles and visual essays, in layouts that broke all the rules — with varying type sizes, overlapping layers, text columns crashing into each other and distorted letterforms, all techniques that the Mac made easier. VanderLans and Licko sold their type designs to fund the magazine (which meant they didn’t have to cater to advertisers).

GI_Emigre_43Aspread-opt
GI_Emigre_49spread-opt
Emigre magazine spreads: Number 43, Number 49

The typefaces13 were an important part of the magazine’s design as well. After the first two issues, the magazine was set exclusively from the collection of Emigre Fonts. Licko began with rough pixelated typefaces, like Oakland, and progressed to more versatile fonts, like the popular Mrs Eaves. Emigre Fonts also carried select designs by Barry Deck, Jonathan Barnbrook, Elliot Earls, Eric Donelan and Bob Aufuldish and Ed Fella, among others.

GI_Emigre_Oakland-opt
Oakland type specimen

The magazine ceased publication in 2005, but Licko continues to design fonts, and VanderLans designs the type specimens. They also sell books, ceramics and collectibles.

GI_Emigre_33Cover-opt
Emigre magazine cover, number 33

John Maeda

John Maeda14 was a computer science graduate student at MIT in the late 1980s on his way to becoming a user interface designer. Then he read Thoughts on Design15, by Paul Rand — an experience that shifted the course of Maeda’s career.

GI_Maeda_mori5-opt
One of ten poster designs for Japanese type foundry Morisawa, 1996

Maeda took a humbling message from Rand’s book: Understanding the computer did not necessarily make one a good designer. Encouraged by his professor Muriel Cooper, Maeda decided to study graphic design in Japan, where he added traditional design skills and concepts to his knowledge of computers.

GI_Maeda_timepaint-opt
Time Paint software for Macintosh, 1994

Maeda then returned to MIT to teach, and founded the Aesthetics and Computation Group at the Media Lab. It was there that Maeda, who as a child excelled at both math and art (though his father only bragged about the math part), explored the area where design and technology meet. For Maeda, the computer is a tool and a medium. Through the Media Lab, Maeda created digital experiences like The Reactive Square, in which shapes responded to sound, and Time Paint, a time-based program of flying colors. His Design by Numbers project (no longer active) encouraged designers and artists to learn computer programming.

GI_Maeda_newshiseido-opt
Shiseido poster celebrating 30 years of commercial films, 1995

In his quest to educate, Maeda writes books, too: The Laws of Simplicity16 outlines his hopes that technology will simplify, rather than complicate, our lives. From 2008 to 2013, Maeda was president of the Rhode Island School of Design. As an educator, he considers creative thinking equally important as technical capability in the development of the leaders of tomorrow. To the emphasis on science, technology, engineering and math — STEM — throughout the country’s educational system, Maeda proposes adding an A for art, to create STEAM. His goal? Not to make the world more high tech, but to make it more humane.

GI_Maeda_MathButterflies-opt
MIT math department poster, 1998

Summary

Of course, digital technology wasn’t the only new development during this era: Design education programs expanded and became more rigorous. Design writing evolved into its own discipline, as practitioners took matters into their own hands by writing articles, books and criticisms that brought new perspectives to the design canon. And designers were — and are — affected and influenced by social, political and cultural changes as they explored new ways to engage their audiences.

Today, people all over the world can communicate with each other like never before. With the rise of the Internet, social media and mobile applications, the user has gained control over how, when and where they access information. The digital revolution continues, and design is sure to play a significant role in shaping the future.

(il, al)

Portions of this article are from the book “Graphic Icons: Visionaries Who Shaped Modern Graphic Design” by John Clifford. Copyright © 2014. Used with permission of Pearson Education, Inc. and Peachpit Press.

Footnotes

  1. 1 http://vimeo.com/54351371
  2. 2 http://ilovetypography.com/2013/01/12/a-firm-turn-toward-the-objective-josef-muller-brockmann-1948-1981/
  3. 3 http://designmuseum.org/designers/wim-crouwel
  4. 4 http://aprilgreiman.com
  5. 5 http://www.museum-gestaltung.ch/en/exhibitions/review/2014/weingart-typography
  6. 6 http://thinkingform.com/2011/06/29/thinking-armin-hofmann-06-29-2011/
  7. 7 http://mitpress.mit.edu/books/bauhaus
  8. 8 http://www.media.mit.edu
  9. 9 https://www.youtube.com/watch?v=Qn9zCrIJzLs
  10. 10 http://www.emigre.com/index.php
  11. 11 http://www.graphics.com/article/herb-lubalin-master-typographic-logo
  12. 12 http://www.miltonglaser.com
  13. 13 http://www.emigre.com/fonts.php
  14. 14 http://www.maedastudio.com/index.php
  15. 15 http://www.amazon.com/Thoughts-Design-Paul-Rand/dp/081187544X
  16. 16 http://lawsofsimplicity.com

The post Icons Of Digital Design appeared first on Smashing Magazine.

Categories: Others Tags:

Intelligent Wearable Devices: 24 Free Apple Watch Templates for Your Perfect Mockup

October 2nd, 2014 No comments

While some manufacturers opt in favor of huger devices and bigger screens, others vice versa prefer going for a more minimalist approach, slimmer gadgets and smaller screens. High technologies do not stand still. They always evolve, progress and improve, endowing masses with top-notch pioneering devices as well as surprising them with really unexpected solutions. The perfect examples for the latter are intelligent accessories that are on everyone’s radars these days.

Categories: Others Tags:

Animated Dark-Comedy – The Missing Scarf Premieres Online

October 2nd, 2014 No comments
squirrel_eoin_duffy

One of the year’s most successful short films is now available online. The Missing Scarf – Animated dark-comedy, masquerading as a classic kid-friendly morality-tale, has racked a mind bending 16 international awards, alongside a nomination for the upcoming European Film Awards, and a shortlisting for the 2014 Academy Awards.. (Clearly doing something right!)

Eoin Duffy, Graphic-designer turned animator

Eoin Duffy, the film’s creator, is a graphic-designer turned animator who jumped ship in 2012 with his first film ‘On Departure’. The Missing Scarf is a continuation of his motion-design style.

George_Takei1

The Legend that is George Takei

The film was produced by Jamie Hogan in conjunction with Belly Creative Ltd., The Irish Film Board, RTE and The Arts Council, along with narration by pop culture legend ‘Uncle’ George Takei.

Categories: Designing, Others Tags:

Animated Dark-Comedy – The Missing Scarf Premieres Online

October 2nd, 2014 No comments
squirrel_eoin_duffy

One of the year’s most successful short films is now available online. The Missing Scarf – Animated dark-comedy, masquerading as a classic kid-friendly morality-tale, has racked a mind bending 16 international awards, alongside a nomination for the upcoming European Film Awards, and a shortlisting for the 2014 Academy Awards.. (Clearly doing something right!)

Eoin Duffy, Graphic-designer turned animator

Eoin Duffy, the film’s creator, is a graphic-designer turned animator who jumped ship in 2012 with his first film ‘On Departure’. The Missing Scarf is a continuation of his motion-design style.

George_Takei1

The Legend that is George Takei

The film was produced by Jamie Hogan in conjunction with Belly Creative Ltd., The Irish Film Board, RTE and The Arts Council, along with narration by pop culture legend ‘Uncle’ George Takei.

Categories: Designing, Others Tags:

What Every App Developer Should Know About Android

October 2nd, 2014 No comments
Testdroid Cloud hosts hundreds of working Android and iOS devices.

In today’s fast-paced mobile market, consumers have no patience for mobile apps that compromise their experience. “Crashes” and “Not working” are the most common feedback1 on Google Play for unstable or sluggish apps (including games). Those comments and ratings make hundreds of millions of potential downloaders skip those lousy apps. Sounds harsh, but that’s the way it is.

An app succeeds not by chance. It is the result of the right decisions made at the right time. The most successful mobile app developers2 understand the importance of performance, quality and robustness across the array of mobile devices that their customers use.

Examples abound of just how easily a developer can go very, very wrong with their app. An app can behave differently on a variety mobile devices3, even ones running the same OS version and identical hardware components.

4
Testdroid Cloud hosts hundreds of working Android and iOS devices. (Image credit: Testdroid145) (View large version6)

During Q1 of this year (1 January to 31 March), we gathered a significant amount of data from Testdroid Cloud7 on tests done by many mobile app and game developers. Testdroid Cloud is an online cloud-based platform for mobile developers to test that their apps work perfectly on the devices that their customers use.

During this period, over 17.7 million tests were run on 288 distinct Android hardware models. To be clear, different versions of some popular models were tested but are counted in the data as one distinct device (such as the Samsung Galaxy S4 GT-i95058 running 4.2.2, API level 17). Some popular devices also had different versions of a single OS, such as the Google Nexus 7 ME370T9 with Android OS version 4.1.2 (API level 16), 4.2.2 (API level 17) and 4.3 (API level 18).

All tests were automated, using standard Android instrumentation10 and different test-automation frameworks11. In case you are not familiar with instrumentation, Android has a tutorial12 that explains basic test automation. Also, the tests caught problems through logs, screenshots, performance analysis, and the success-failure rate of test runs.

Note: The data includes all test results, from the earliest stage (=APK ready) to when the application gets “finalized.” Therefore, it includes the exact problems that developers encountered during this process.

13
The research statistics, testbed and global coverage. (Image credit: Testdroid145) (View large version15)

The goal for this research was to identify the most common problems and challenges that Android developers face with the devices they build for. The 288 unique Android device models16 represent a significant volume of Android use: approximately 92 to 97% of global Android volumes, depending on how it gets measured and what regions and markets are included. This research represents remarkable coverage of Android usage globally, and it shows the most obvious problems as well as the status of Android hardware and software from a developer’s point of view.

We’ll dive deep into two areas of the research: Android software17 and hardware18. The software section focuses on OS versions and OEM customizations, and the hardware section breaks down to the component level (display, memory, chipset, etc.).

Android Software

Your app is software, but a lot of other software is involved in mobile devices, too. And this “other” software can make your software perform differently (read “wrong”). What can you do to make sure your software works well with the rest of the software in devices today? Let’s first look at some of the most common software issues experienced by app developers.

Android OS has been blamed for platform fragmentation19, making things very difficult for developers, users and pretty much every player in the ecosystem to keep up. However, that is not exactly the case. The OS very rarely makes things crack by itself — especially for app developers. More often it also involves OEM updates, hardware and many other factors — in addition to the OS.

Data collected during a 7-day period ending on July 7, 2014.20
Data collected for seven days, ending on 7 July 2014. (Image credit: Google21) (View large version22)

One reason why Android is tremendously popular among mobile enthusiasts and has quickly leaped ahead of Apple’s iOS in market share is because it comes in devices of all shapes23, prices and forms, from tens of different OEMs.

Also, the infrastructural software of Android24 is robust, providing an excellent platform with a well-known Linux kernel, middleware and other software on top. In the following sections, we’ll look at the results of our research, broken down by OS version, OEM customizations and software dependencies.

How to Read the Graphs

The findings from this study are plotted on graphs. In those graphs, the dark black line is the median (50%) of the failure percentage of different devices in that group. The lines above the bars mark the upper quartile (75%), and the lines below mark the lower quartile (25%). The dashed lines are the maximum (top or right) and minimum (bottom or left). The circles represent outliers.

OS And Platform Versions

We’ll start with the most important factor in the problems experienced by app developers: Android OS versions25. This dramatically affects which APIs developers can use and how those APIs are supported in variety of devices.

Many developers have experienced all of the great new features, improvements and additions that Android has brought version by version26. Some late-comers have played with only the latest versions, but some have been developing apps since the early days as days of Cupcake (1.5) and Doughnut (1.6). Of course, these versions are not relevant anymore.

The following table shows the release dates for the various OS versions (along with their code names) and notes why certain versions were excluded or were not used on the devices being tested.

The Release version for each OS version.27
The release version of each OS version. (Image credit: Testdroid75726966625349433128) (View large version29)

The most typical situation with app developers who want to maximize support for all possible variants is that they’ll start testing from version 4.0 (Ice Cream Sandwich, API level 14). However, if you really want to maximize coverage, start from version 2.3.3 (Gingerbread, API level 10) and test all possible combinations up to the latest release of Kit Kat (currently 4.4.4 and, hopefully soon, Android L). Versions older than 4.0 still have serious use — and will continue to for some time.

The Failure Rate by Each OS Version.30
The failure rate of each OS version. (Image credit: Testdroid75726966625349433128) (View large version32)

When it comes to the latest versions of Android — and let’s count Ice Cream Sandwich (4.0.3 to 4.0.433), Jelly Bean (4.1.1 to 4.334) and Kit Kat (4.4 to 4.4.235) among them — Ice Cream Sandwich is clearly the most robust platform. OEM updates were obviously the least problematic on this version, and the majority of tested apps worked very well on API level 15 (4.0.3 to 4.0.4).

The upgrade to Jelly Bean and API level 16 didn’t significantly introduce new incompatibility issues, and the median failure percentage remained relatively low. However, API level 16 had many outlier cases, and for good reasons. For instance, more problems were reported with Vsync, extendable notifications and especially with support for the lock screen and home screen rotation.

API level 17 brought improvements to the lock screen, and this version was generally stabile up to version 4.2.2. The failure rate went up when the majority of OEMs introduced their updates to this version. Apparently, it became more problematic for users than previous versions.

Perhaps most surprisingly, the failure rate went up36 when Kit Kat API level 19 was released. The average failure percentage reached nearly the same level as it was with Gingerbread. Google patched Kit Kat quite quickly with two releases (4.4.1 and 4.4.2). Of those, 4.4.2 seemed to live much longer, and then the 4.4.3 update came out more than half a year later.

Key Findings From OS Versions

  • On average, 23% of apps behave differently when a new version is installed. The median error percent was the smallest with Ice Cream Sandwich (1%), then Jelly Bean (8%), Honeycomb (8%), Kit Kat (21%) and, finally, Gingerbread (30%). This is actually lower than what was found in the study conducted with Q4 data (a 35% failure rate).
  • Despite old Android versions being used very little and Gingerbread being the oldest actively in use, some applications (40% of those tested) still work on even older versions (below 2.2). In other words, if an app works on version 2.2, then it will work 40% of the time in even older versions as well.
  • Over 50% of Android OS updates introduced problems that made apps fail in testing.
  • Testing failed 68% of the time when 5 apps were randomly picked out of 100.
  • The average duration of testing was 57 cycles per platform. Old versions were tested less than new ones: Gingerbread (12 test cycles), Ice Cream Sandwich (17), Jelly Bean (58) and Kit Kat (95).
  • An average testing cycle reduced 1.75% of bugs in the code overall.

Note: A test cycle constitutes an iteration of a particular test script executed in one app version. When an app is changed and the test remains the same, that is counted as a new test cycle.

Tips and Takeaways

  • For maximal coverage either geographically or globally, using as many physical devices as possible is recommended. Track your target audience’s use of different OS versions. The global status of versions is available on Google’s dashboard37.
  • All OS versions above 2.3.3 are still relevant. This will not likely change soon because users of Gingerbread and Ice Cream Sandwich represent nearly one quarter of all Android users, and many of them do not update (or would have done so already).
  • If you want to cover 66% of OS volume, then testing with Kit Kat (4.4.x) and Jelly Bean (4.1 to 4.3) is enough (covering API 16 to 19).
  • To cover 75% of OS volumes, then test from version 4.0.3 (API level 15).
  • We recommend testing the following devices to maximize coverage:
    • Amazon Kindle Fire D01400 — 2.3.4
    • HTC Desire HD A9191 — 2.3.5
    • Huawei Fusion 2 U8665 — 2.3.6
    • Sony Xperia U ST25i — 2.3.7
    • Asus Eee Pad Transformer TF101 — 4.0.3
    • LG Lucid 4G — 4.0.4
    • HTC One S X520e — 4.1.1
    • Motorola Droid XYBOARD 10.1 MX617 4.1.2
    • Acer Iconia B1-A71 — 4.2
    • BQ Aquaris 5 HD — 4.2.1
    • HTC One mini M4 — 4.2.2
    • Samsung Galaxy Note II GT-N7100 — 4.3
    • LG Google Nexus 5 D821 — 4.4
    • HTC One M8 — 4.4.2

Note: These devices were selected because they are a good base to test certain platform versions, with different OEM customizations included. These devices are not the most problematic; rather, they were selected because they provide great coverage38 and are representative of similar devices (with the same version OS, from the same manufacturer, etc.).

OEM Customizations

One stumbling block with Android — like any open-source project — is its customizability, which exposes the entire platform to problems. What is called “fragmentation” by developers would be considered a point of differentiation for OEMs. In recent years, all Android OEMs have eagerly built their own UI layers39, skins and other middleware on top of vanilla Android. This is a significant source of the fragmentation that affects developers.

In addition to UI layers, many OEMs have introduced legacy software40 — tailored to Android — and it, too, is preventing developers from building their apps to work identically across different brands of phones.

Drivers also cause major problems41, many related to graphics. Certain chipset manufacturers have done an especially bad job at updating their graphics drivers, which makes the colors in apps, games and any graphic content inconsistent across phones. Developers might encounter entirely different color schemes on various Android devices, none close to what they intended.

Failure rate by OEM.42
Failure rate by OEM. (Image credit: Testdroid75726966625349433128) (View large version44)

Key Findings Related to OEM Customizations

  • No surprise, Samsung devices are among the most robust and the most problematic. For example, Galaxy Nexus GT-I9250 is one of the most robust devices in all categories, while the Samsung Infuse 4G SGH-I997 failed the most in those same categories.
  • Asus devices, along with Xiaomi devices, are the most robust. Xiaomi implements Android differently, however; for instance, pop-ups make the controllability of some devices impossible.
  • Coolpad has, by volume, the most problems. Among the biggest brands, HTC has the least error-prone devices.
  • All of the big brands — HTC, Samsung, Sony and LG — have customizations that are problematic for certain types of applications. For example, Sony’s customizations breaks some basic functionality, such as viewing PDFs. Samsung’s customizations has problems with taking photos with the camera and interrupting calls.

Tips and Takeaways

  • The most common misconception is that Nexus devices are the best for testing. Those devices typically have the latest OS version and little to no OEM customization.
  • Pay attention to carrier- and operator-branded devices as well. Some of them implement Android totally differently, regardless of the name of the device or brand.

Dependencies On Other Software

Some applications require access to other apps. For example, many apps and games incorporate social media, and in the worst implementations, developers have assumed that every device integrates popular social media apps. Some devices come with those social media apps preinstalled, but if not, then your application just won’t work properly. Unfortunately, problems with software dependency turn into problems for app developers.

Key Findings Related to Dependencies on Other Software

  • 92% of apps integrate with the given platform to show ads.
  • 65% of apps integrate with at least one social media platform.
  • 48% of apps integrate with at least two social media platforms.
  • 33% of apps integrate with at least three or more social media platforms.

Tips and Takeaways

Check whether the software that your application depends on is installed on all devices. Do not assume that all of those third-party apps and other software exist on every device!

Android Hardware

The Android device eco-system continues to grow and evolve. Many handset manufacturers continue to churn out devices with amazing specifications and hardware and with different form factors. Naturally, the sheer number of possible device configurations45 presents a challenge to developers. Ensuring that an application works well on the widest range of devices is crucial and is the easiest way to avoid frustrating end users.

Most developer carefully weigh the pros and cons of testing on emulators and testing on real devices46 to follow the right strategy. Typically, emulators are used in initial stages of development, while real devices are brought in later in the game. Your choice of platform on which to build your next big thing should be as honest as possible — from day one. In our experience, that is a cornerstone of creating a successful app — and gaining those hundreds of millions of downloads.

Screen Resolution, Display and Colors

The key to success with any app — especially games — is to get the UI and graphics right. This is a challenge because there are a lot of different resolutions, a lot of ways to present content and, naturally, a lot of different hardware.

With new high-end devices gaining popularity among users, the Android eco-system seems to be quickly headed towards high-resolution displays. High-resolution screens obviously make for a better user experience, but to take advantage of this, developers need to update their apps and test for them47.

Identical app on 3 different Android devices running identical OS version and hardware.48
Can you see the difference? An identical app is running on three different Android devices with the same OS version and hardware specifications. (Image credit: Testdroid75726966625349433128) (View large version50)

However, display resolution51 is not always the cause of headaches for developers. In fact, applications fail more often because of screen orientation, density, color and the overall quality of the device’s screen. For example, many games suffer from poor-quality displays. For instance, a button in a certain part of the UI might get shown in a different shade than the one intended by the designer — or, in some cases, a totally different color.

This is a common issue. It can result not only from hardware components, but also when display drivers are implemented incorrectly. Graphical content could even be invisible in some apps because of color brightness or low pixel density. This kind of failure is apparent from screenshots in our tests.

Failure rate by screen resolution52
Failure rate by screen resolution. (Image credit: Testdroid75726966625349433128) (View large version54)

No surprise that as the display resolution gets higher, apps present fewer problems. There are a few exceptions to this, but they can be attributed to how certain OEMs use various resolutions55 in both low- and high-end devices.

The Android OS provides a environment to develop apps consistently56 across devices, and it handles most of the work of adjusting each application’s UI to the given screen. Also, it comes with APIs that enables the developer to optimize an application’s UI for a particular screen size or density57. For example, you might want one UI for tablets and another for handsets. Although the OS scales and resizes to make an application work on different screens, you should still optimize your application for different screen sizes58 and densities. In doing so, you’ll improve the user experience on all devices, and users will believe that your application was designed for their particular device, rather than simply stretched to fit their screen.

Key Findings Related to Screen Resolution

  • The median of error was the smallest in resolutions of 2560 × 1600 pixels (0.4%), then 1280 × 800 (0.7%) and 1280 × 720 pixels (1.5%). It was highest in resolutions of 400 × 240 (45%) and 320 × 240 pixels (44%).
  • The most typical problem relates not to resolution or the scaling of graphical content, but to how content adjusts to the orientation of the screen. According to our data, problems with screen orientation are 78% more likely than problems with the scaling of graphical content.
  • Wrong color themes and color sets were reported in 18% of devices, while 24% of apps appeared correctly on all 288 different devices.
  • In some cases, an Android OS update or OEM update fixed a display issue, but the percentage was relatively low (6%).
  • Apps worked nearly the same on high- and low-end devices (based on chipset) with the same resolution (just a 2% difference).
  • In general, the bigger a device’s display, the more likely an app will perform better.

Tips and Takeaways

  • Design graphical content for multiple screen sizes, but make it scale to different sizes automatically. This is strictly a design issue.
  • Many problems with resolution, display and color can be avoided by designing an application correctly in the first place and by testing it thoroughly on real Android devices. Emulators won’t yield reliable results or lead to a robust application.

Memory

Anything can happen when an Android device runs out of memory59. So, how does your application work when a device is low on memory?

Developers deal with this problem rather often. Many apps won’t run on certain Android devices because they consume too much memory. Typically, the most popular apps60 — ones rated with four and five stars — do not have this problem because memory management has been implemented the right way, or else they have been excluded from being downloaded on low-end devices entirely. Too many of today’s apps were originally developed for high-end devices and can’t be run on low-end devices. What is clear is that you can easily tackle this problem by checking how your app works with different memory capacities.

Memory seems to significantly affect how a device copes with an application. If a device’s RAM is equal to or less than 512 MB, then the device will crash 40% of the time when certain applications are running.

Failure rate of apps by memory size of device61
Failure rate of apps by memory size of device. (Image credit: Testdroid75726966625349433128) (View large version63)

If a device’s RAM is higher than 512 MB, then the device will crash approximately 10% of the time. That is statistically significant.

Key Findings Related to RAM

  • The median of error was lowest with RAM of 1024 MB (1%), then 1536 MB (3%) and next 768 MB (16%). It was highest with RAM of 336 (45%) and 168 MB (44%).
  • Approximately 10% of apps run on devices with more than 512 MB crash due memory-related issues.
  • Many OEMs do not give their devices the 512 MB of RAM that Google recommends as the minimum. Such devices are 87% more likely to have problems than devices with more memory.
  • The probability of failure drops 41% for devices that contain more than 576 MB of memory.

Chipsets

The difference in performance between silicon chipsets64 (CPU, GPU, etc.) is pretty amazing. This is not necessarily obvious to end users. Some people pay too much attention to the CPU’s clock rate, rather than the chipset and other factors that affect the performance of the device.

Imagine developing something that is targeted at high-end devices but that runs on low-end hardware. It simply wouldn’t work. The user experience would obviously suffer because a high-end app running on a low-end chipset with a low clock-frequency rate would suffer in performance. Many apps suffer severely because the activities on screen are synced with the clock, and the UI can’t refresh quickly enough to keep up with it. For users, this translates into poorly implemented graphics, blinking screens and general slowness.

Failure rate of apps by device clock rate65
Failure rate of apps by device clock rate. (Image credit: Testdroid75726966625349433128) (View large version67)

Let’s first look at the clock rate of devices that we tested.

To compare chipsets more easily, we categorized them based on their number of cores: single, dual and quad.

Failure rate by single-core chipset68
Failure rate by single-core chipset. (Image credit: Testdroid75726966625349433128) (View large version70)
Failure rate by dual-core chipset71
Failure rate by dual-core chipset. (Image credit: Testdroid75726966625349433128) (View large version73)
Failure rate by quad-core chipset. width=74
Failure rate by quad-core chipset. (Image credit: Testdroid75726966625349433128) (View large version76)

Unlike the CPU architecture in chipsets — which is manufactured primarily by ARM77 — the graphics portion is manufactured by multiple vendors, which gives some semiconductor companies the flexibility to pick and choose which GPU goes best with the CPU in their chipsets.

Back in the day, the primary job of the graphics card was to render high-end graphical content and 3-D images on the screen. Today, GPUs are used for much more than games and are as crucial as the CPU, if not more so.

Today, all of the recent Android OS versions — Ice Cream Sandwich, Jelly Bean, Kit Kat and so on — rely heavily on the GPU because the interface and all animations are rendered on it, which is how you’re able to achieve transition effects that are buttery smooth. Today’s devices have many more GPU cores than CPU cores, so all graphics and rendering-intensive tasks are handled by them.

Key Findings Related to Chipset

  • Single core
    The median of error was lowest in Intel Atom Z2420 (0.2%), then in Qualcomm Snapdragon S2 MSM8255T (1.1%).
  • Dual core
    The median of error was lowest in MediaTek MT8317 (0.3%), then in Intel Atom Z2560 (0.4%).
  • Quad core
    The median of error was lowest in both MediaTek MT8125 (0.2%) and Qualcomm Snapdragon 600 APQ8064AB and APQ8064T (0.2%).
  • Many high-end devices are updated to the latest version of Android and get the latest OEM updates, which makes them more vulnerable to problems (67%) than low-end devices with the original OS version.
  • Clock rate doesn’t directly correlate with performance. Some benchmarks show significant improvement in performance, even when the user experience and the apps on those chipsets and devices don’t improve significantly.
  • Power consumption is naturally a bigger problem in some batteries, and some devices run out of battery life quickly. However, this is tightly related to the quality and age of the battery and cannot be attributed solely to the chipset.

Tips and Takeaways

  • Thoroughly test your application on all kinds of devices — low end, mid-range and high end — if it has heavy graphics (such as apps with video streaming) or uses the GPU heavily, to ensure maximal performance across an ecosystem.
  • Do not assume that your app works across different chipsets. Chipsets have a lot of differences between them!

Other Hardware (Sensors, GPS, Wi-Fi, etc.)

Misbehaving sensors — and we’re not talking about sensors that are poorly calibrated78 or that cannot be calibrated — cause various problems in games that take input from the way the user handles the device. With GPS, the known problems are navigating indoors and not being able to reach satellites from some locations. To take a similar example with media streaming, video that is meant to be viewed in landscape mode might work well in landscape mode, but the user would have to rotate the device 180 degrees to see it right. Frankly, there is no way to properly test orientation with an emulator; also, things related to the accelerometer, geo-location and push notifications cannot be emulated or could yield inaccurate results.

Network issues come up every now and then, and a slow network will very likely affect the usability and experience of your application.

Conclusion

In this article, we’ve focused on two areas — Android software and hardware — and what app developers need to know about both. The Android eco-system is constantly changing and new devices, OS versions and hardware come out every week. This naturally presents a big challenge to application developers.

Testing on real devices prior to launch will make your app significantly more robust. In the next article, we will dive deep into this topic, covering the most essential testing methods, frameworks, devices and other infrastructure required to maximize testing.

How do you test mobile apps, and what devices do you use and why? Let us know which aspects of mobile app testing you would like us to cover in the next article.

(da, al, ml, il)

Footnotes

  1. 1 http://news.sky.com/story/1320558/downloads-drop-as-appetite-for-new-apps-wanes
  2. 2 http://www.appannie.com/indexes/all-stores/rank/overall/
  3. 3 http://www.androidcentral.com/devices
  4. 4 http://www.smashingmagazine.com/wp-content/uploads/2014/09/01-testdroid-phones-opt.jpg
  5. 5 http://www.testdroid.com/
  6. 6 http://www.smashingmagazine.com/wp-content/uploads/2014/09/01-testdroid-phones-opt.jpg
  7. 7 http://www.testdroid.com/
  8. 8 http://pdadb.net/index.php?m=specs&id=4234
  9. 9 http://pdadb.net/index.php?m=specs&id=3929
  10. 10 http://developer.android.com/tools/testing/testing_android.html#Instrumentation
  11. 11 http://en.wikipedia.org/wiki/Test_automation#Framework_approach_in_automation
  12. 12 http://developer.android.com/tools/testing/testing_android.html
  13. 13 http://www.smashingmagazine.com/wp-content/uploads/2014/09/02-testdroid-infography-opt.jpg
  14. 14 http://www.testdroid.com/
  15. 15 http://www.smashingmagazine.com/wp-content/uploads/2014/09/02-testdroid-infography-opt.jpg
  16. 16 http://opensignal.com/reports/fragmentation-2013/
  17. 17 http://en.wikipedia.org/wiki/Android_version_history
  18. 18 http://tech.firstpost.com/news-analysis/all-you-need-to-know-about-mobile-phone-chipsets-27704.html
  19. 19 https://developer.android.com/about/dashboards/index.html
  20. 20 http://www.smashingmagazine.com/wp-content/uploads/2014/09/03-android-os-distribution-opt.png
  21. 21 https://developer.android.com/about/dashboards/index.html
  22. 22 http://www.smashingmagazine.com/wp-content/uploads/2014/09/03-android-os-distribution-opt.png
  23. 23 http://developer.android.com/training/design-navigation/multiple-sizes.html
  24. 24 http://en.wikipedia.org/wiki/Android_(operating_system)#Software_stack
  25. 25 http://en.wikipedia.org/wiki/Android_version_history
  26. 26 http://www.smashingmagazine.com/2013/05/08/brave-new-world-designing-for-a-maturing-android/
  27. 27 http://www.smashingmagazine.com/wp-content/uploads/2014/09/04-q1-releasedates-opt.png
  28. 28 http://www.testdroid.com
  29. 29 http://www.smashingmagazine.com/wp-content/uploads/2014/09/04-q1-releasedates-opt.png
  30. 30 http://www.smashingmagazine.com/wp-content/uploads/2014/09/05-q1-failed-releaseVersion-opt.png
  31. 31 http://www.testdroid.com
  32. 32 http://www.smashingmagazine.com/wp-content/uploads/2014/09/05-q1-failed-releaseVersion-opt.png
  33. 33 http://en.wikipedia.org/wiki/Android_version_history#Android_4.0.3.E2.80.934.0.4_Ice_Cream_Sandwich_.28API_level_15.29
  34. 34 http://en.wikipedia.org/wiki/Android_version_history#Android_4.1_Jelly_Bean_.28API_level_16.29
  35. 35 http://en.wikipedia.org/wiki/Android_version_history#Android_4.4_KitKat_.28API_level_19.29
  36. 36 https://community.verizonwireless.com/thread/824084
  37. 37 http://developer.android.com/about/dashboards/index.html
  38. 38 http://opensignal.com/reports/fragmentation-2013/
  39. 39 http://www.tested.com/tech/android/460386-state-oem-skins-android/
  40. 40 http://forum.xda-developers.com/showthread.php?t=2570435
  41. 41 http://www.xda-developers.com/android/three-all-in-one-solutions-for-android-driver-issues/
  42. 42 http://www.smashingmagazine.com/wp-content/uploads/2014/09/06-q1-failed-oneCore-color-opt.png
  43. 43 http://www.testdroid.com
  44. 44 http://www.smashingmagazine.com/wp-content/uploads/2014/09/06-q1-failed-oneCore-color-opt.png
  45. 45 http://opensignal.com/reports/fragmentation-2013/
  46. 46 http://insights.wired.com/profiles/blogs/the-best-advice-for-app-developers-skip-emulators#axzz38bhWO19j
  47. 47 http://testdroid.com/testdroid/5876/test-early-test-often-testing-as-part-of-your-app-development
  48. 48 http://www.smashingmagazine.com/wp-content/uploads/2014/09/07-color-error-opt.jpg
  49. 49 http://www.testdroid.com
  50. 50 http://www.smashingmagazine.com/wp-content/uploads/2014/09/07-color-error-opt.jpg
  51. 51 http://developer.android.com/guide/practices/screens_support.html#testing
  52. 52 http://www.smashingmagazine.com/wp-content/uploads/2014/09/08-q1-failed-screenReso-opt.png
  53. 53 http://www.testdroid.com
  54. 54 http://www.smashingmagazine.com/wp-content/uploads/2014/09/08-q1-failed-screenReso-opt.png
  55. 55 http://developer.android.com/about/dashboards/index.html
  56. 56 http://www.smashingmagazine.com/2014/01/10/four-ways-to-build-a-mobile-app-part2-native-android/
  57. 57 http://www.smashingmagazine.com/2012/06/01/getting-to-know-android/
  58. 58 http://www.androiduipatterns.com/
  59. 59 https://source.android.com/devices/low-ram.html
  60. 60 http://www.appannie.com/indexes/all-stores/rank/overall/
  61. 61 http://www.smashingmagazine.com/wp-content/uploads/2014/09/09-q1-failed-ram-opt.png
  62. 62 http://www.testdroid.com
  63. 63 http://www.smashingmagazine.com/wp-content/uploads/2014/09/09-q1-failed-ram-opt.png
  64. 64 http://tech.firstpost.com/news-analysis/all-you-need-to-know-about-mobile-phone-chipsets-27704.html
  65. 65 http://www.smashingmagazine.com/wp-content/uploads/2014/09/10-q1-failed-cpu-opt.png
  66. 66 http://www.testdroid.com
  67. 67 http://www.smashingmagazine.com/wp-content/uploads/2014/09/10-q1-failed-cpu-opt.png
  68. 68 http://www.smashingmagazine.com/wp-content/uploads/2014/09/11-q1-failed-oneCore-opt.png
  69. 69 http://www.testdroid.com
  70. 70 http://www.smashingmagazine.com/wp-content/uploads/2014/09/11-q1-failed-oneCore-opt.png
  71. 71 http://www.smashingmagazine.com/wp-content/uploads/2014/09/12-q1-failed-dualCore-opt.png
  72. 72 http://www.testdroid.com
  73. 73 http://www.smashingmagazine.com/wp-content/uploads/2014/09/12-q1-failed-dualCore-opt.png
  74. 74 http://www.smashingmagazine.com/wp-content/uploads/2014/09/13-q1-failed-quadcore-opt.png
  75. 75 http://www.testdroid.com
  76. 76 http://www.smashingmagazine.com/wp-content/uploads/2014/09/13-q1-failed-quadcore-opt.png
  77. 77 http://www.arm.com
  78. 78 http://android.stackexchange.com/questions/59532/how-can-i-calibrate-the-tilting-sensor-on-android

The post What Every App Developer Should Know About Android appeared first on Smashing Magazine.

Categories: Others Tags:

Deal of the Week: John Forsythe’s 2014 Photoshop Text Effects Collection of 3,100+ Elements (NOT for 99$)

October 1st, 2014 No comments

We know you like text effects. And – no doubt – text effects are a proven way to impress. As it is with everything impressive, the effects are bound to wear off over time. That’s why you will want to make sure you always got the freshest, most recent effects at hand. The free stuff already available is so wildly popular, you see it on every other corner of the web. But. You don’t want your creations to look like everybody else’s, do you? Keep calm and read on…

Categories: Others Tags: