Spark

Subscribe via Email

Subscribe to RSS feed

Archives

Android Version Deprecation

The latest version of Adobe Cordova was released today (v. 3.5) and perusing through the release notes, I saw that they had dropped support for iOS 5, leaving only one major previous release (iOS 6) and the current release. In the past, Android developers have been plagued by the slow release of new versions of the Android SDK to existing Android phones. It has only been in the past year or so that a significant number of developers have moved off supporting 2.3.3 (Gingerbread) and below, making the lowest androidversion number supported being 4.0.3. The question for Android developers is: how aggressively can they move off of 4.0.3 to the next major release, 4.1?

Taking a quick check of the Android smartphones available through the various carriers, none of the phones are lower than 4.1 but a number are at 4.1 (example, the LG Enact and Motorola Droid RAZR M) so, unlike Apple, we as developers cannot move back to only 4.2 and eliminate phones that are still being sold by the major carriers. In all likelihood, the 4.0.3 phones are those who are waiting for their 2-year contract to come up, knowing that the phone will be not be updated by the carrier or OEM. Dropping 2.3.3 loses a developer about 16% of the market but gains in terms of lower bug count (quite a few issues are performance related, trying to use a modern mobile app on older hardware) and a wider selection of third-party tools (which have abandoned 2.3.3 and many are 4.1 and above).

The key issue is supporting 4.0.3 and its 13.4% share. The developer has to determine how resource-intensive the app is and what is the risk of users trying to run it on 4.0.3 (which are also resource-limited) and the subsequent crashes due to memory errors. It is difficult to justify to management a proposal that shuts out almost 30% (2.3.3’s 16.2% and 4.0.3’s 13.4%) of a customer base but the bigger question is: does it make business sense to support a project when the funds required exceeds the return of investment and the risk of poor acceptance in the marketplace when the app’s performance requirements exceeds the user’s hardware at the low end of the curve?

One other consideration I failed to mention is usage by the international market. If the mobile app is targeted outside of the United States/Canada, many lower-end Android phones (white-box, introductory) sold in India, China and Africa are still using 2.3.3/Gingerbread. In the case of tablets, even the low-end 8 GB/under a $100.00 models are supporting Android 4.1 and above (source: Walmart.com).

Posted in Android, Mobile, Musings

Myths & Facts – Websphere Portal and UI.

Having worked as a front end developer, integrating the UI with backend systems, I am presenting below some of the myths and facts concerning UI (html, css, javascript, images, fonts) code integration with websphere portal and a few best practices one should follow -

Myth – Websphere portal is not compatible with latest front end frameworks like bootstrap, foundation, jQuery Mobile, etc.

Fact – Websphere portal is completely compatible with all the latest front end frameworks and there should be no reason why one should be concerned about including the front end framework in the portal. Basically, the front end frameworks include a css file, which is responsive, follows a grid system, provides styling for UI elements and takes care of accessibility and cross browser compatibility to an extent. The html in the portal will only be referencing the class names that are defined in the framework’s css file, enhancing the user experience and this css file is included in the portal theme.

Myth – Websphere portal is not compatible with jQuery and associated plugins.

Fact – Websphere portal comes with dojo javascript library as the default framework and many of the portal elements like WCM, use dojo’s javascript functionality for client side manipulation. However, on starting a new project, there are certainly workarounds available to make sure portal’s dojo does not interfere with jQuery. On a websphere portal 8 project – starting from scratch, if there is no dojo being used(by the portal theme and associated portlets) but only referenced in the portal, then jQuery should be working fine without any issues. We might see some conflicts if we try to use both dojo functions and jQuery functions, but using only one of them with the other being referenced (like portal needs dojo reference), should be just fine.

Myth – All the css, javascript, images associated with a portlet should be inside that portlet.

Fact – This is a bad practice. All of the css, behavioral javascript and images for each portlet should be in the portal theme. Because, if you have 3 portlets on a page, then the page load would take a long time, as when each of the portlet loads, its associated css, js and images will also load then. But if you are loading all of them at the bottom of the page in the theme, then the portlets would be rendered without the interference of static assets, which get loaded at the bottom. There are various compression and minifying tools available to reduce the load size and http requests of these static assets. This way, an UI developer has direct access to all of the portal’s static assets, in the theme, can make changes and deploy, while really not worrying about making changes to each individual portlets.

Myth – To make a change in the css file, this should be done in the portal theme, deployed to QA, tested and then served to production.

Fact – In today’s web development world, where the UI is constantly changing and more changes to the css is needed as expected earlier, the changes to css in the theme, deployed, tested and served to production is a tedious and long process. As an alternative, the css file for the whole portal theme can reside in a web server or IHS (IBM HTTP Server), and then referenced in the theme. Both the UI developer and the portal developer should have access to this web server, so that changes can be done directly to this css file and pushed to any environment without the need for a deployment. Same goes for library javascript files and images.

Best Practices a Front End Developer needs to follow while working with portal theme.

1. For prototyping, use a build tool and a generator such as yeoman build and grunt tasks. This would throw up production ready, testable, minified, compressed static assets – css, images and javascript.

2. Move the css to a web server or IHS and reference this css in the theme from the web server so that, any change to the css does not really require a theme deployment. All it needs is front end developer access to the web server. Same goes with library javscripts (jQuery, plugins, etc) and images. To swap a logo, it can be done in the images folder on a web server, tested in QA, pushed to staging, verified and finally served in the production.

3. Make sure there is no inline javascript inside the portlet, as this greatly affects page load performance. All the javascript should be loaded at the bottom of the page. There should be no library files in the portlet, as this would result in conflicts between different library versions among different portlets.

4. If you are parsing large json data and integrating that with the html in the jsp of the portlet, then just throw up the json on the portlet. Make use of handlebar or mustache templates to parse the json and inject that json data directly in the html. This helps in separating the html from the data and also any changes to the html can be done without altering backend logic.

Minimal Viable Product

In a conversation the other day, the focus was around the integration of the Agile methodology with Lean Startup and the cycle of build > measure > learn and how concepts from Lean Startup can complement an Agile software development process. One of the intriguing ideas that carry over into enterprise mobile development is a Minimal Viable Product or MVP. Quite a bit has been written this year about moving to a “mobile first” Minimal Viable Productenterprise, especially as the threshold of “7.1 Billion people and 7.1 Billion mobile phone subscriptions worldwide” has been reached. Corporate IT needs to adapt to this new way of working or run the risk of employees and managers bypassing the IT organization and creating a large shadow IT environment. There have been numerous examples in the past, the one that comes to mind is the Microsoft Access-based systems that cropped up in enterprise departments in the 1990s when IT could not meet the needs of business and so departments created their own IT systems and thus, silos of data with no interoperability. Corporate IT needs to get ahead of this new wave and demonstrate to the business that they are the right organization implement and manage it. It is imperative for IT to embrace mobile by examining how to enable mobile applications and understand the challenges of a “mobile first” environment. The question becomes, how does IT do that?

So, back to the original topic which was the Minimal Viable Product or MVP. IT needs to work with business to identify problems that are occurring within the organization and look to solve it through mobile. In the case of software development, a minimal viable product (MVP) is a software product that meets the minimum requirements of the end user so that these users can test the product and offer immediate feedback to the mobile development team to iterate on. The feedback is reviewed and incorporated into the next build of the product. Releasing the MVP frequently demonstrates to the end users that a) they have a voice into the mobile app’s design and b) the IT organization is attempting to meet the mobile needs of the business. Creating a number of MVPs targeted at various segments of the business user community with an organization allows IT to understand what these groups are looking for, what is useful and how the IT infrastructure needs to adapt to support mobile. Those MVPs that “scratch the itch” of the user community can be further developed into a valuable enterprise mobile application and discard the ones that do not add value.

One word of warning however, as Abraham Wallin pointed out in his article: Lost in Translation: The Minimal Viable Product, the word “Viable” seems to be pushed into the shadows of “Minimal”. A minimal viable product cannot be poorly designed, all of the learning and feedback from the end users is lost and it will be difficult to get the end users engaged for any subsequent releases or other mobile products created by IT. Creating an MVP requires an entire team of UX, interface design and development so that, even though the product may only have a subset of functionality, it meets base quality and usability standards.

Posted in Mobile, Musings, Trends

The Collaborative Economy

A key question for today business is how to turn their brand into a platform. It’s thinking terms of systems platforms for e-commerce, social, search and so on that has transformed the digital landscape. Without what has become massive, internet-scale platforms these businesses would not exist.

It is time for well established companies to view their brand, information, products and services as a potential revenue generating platform.

Implementing a collaborative platform requires the technology that the now established platform players have created – Cloud, Big Data, Mobility, APIs, engaging user experience and scalable platforms.

How can your company directly improve their brand image, monetize collected data, and deliver goods and services more efficiently in a Collaborative Economy? Perficient is working on these opportunities every day and these are exciting times.

5 Signs That The Collaborative Economy Is Going Through Puberty - Many of these platforms are continuously shifting their community experience and business model, learning from one another. Increasingly, the emphasis is shifting from the voice of the company to the voice of the crowd. Established brands are opening up their once vertically integrated value chains and are actively turning products into platforms, often through partnerships. Auto manufacturers worldwide are expanding into car sharing, ride sharing, and have declared themselves to be in the mobility business.

Tags: , , ,

Posted in Digital, News

Flex that Box Model!

The CSS Flexible Box Layout Module Level 1 (or Flexbox) is a box model specification in which the children of a flex container can be laid out in any direction, and can “flex” their sizes, either growing to fill unused space or shrinking to avoid overflowing the parent.  In other words, it’s a neat way for front-end developers to layout content in a way that isn’t just “left to right, top to bottom”.

Flex that Box ModelBut I’m not here to tell you what Flexbox is, nor am I here to tell you how to use it.  At the end of this post are a few links that can cover that for you well enough.  No, what I’m here to tell you is that right now you in fact can use Flexbox.  Go ahead!  Use it!  Before vender prefixes were added, browser support for Flexbox had been sporadic and not very well adopted.  It was possible to use Flexbox on any project you wanted, but the problem was it wouldn’t work on a majority of browsers and mediums.  Now (looking at this Can I Use chart), adoption is so widespread it’s almost universal.

The only problem is (say it isn’t so!) Internet Explorer.  Trying to use the flex box model on anything earlier than IE10 just isn’t going to work.  This is the main issue, and unfortunately it’s a pretty dang big issue.

The solution? Go ahead and use Flexbox, just be sure to contain it to mobile devices (or progressive enhancements).  Most uses that I’ve had for needing to adjust the box model layout in a way that required Flexbox were design changes from desktop to mobile devices. Say you’ve got a two column layout with your main content and a right-hand sidebar.  If you wanted that sidebar information to float to the top of your page on a mobile device above the main content, you were going to have a difficult time. With Flexbox however, it’s pretty simple. And if used in conjuncture with media queries or Modernizr, keeping any usages of Flexbox limited to mobile device should be simple as well.

At the time of this posting, I’m not aware of any shims or polyfills to make Flexbox work on IE9 and earlier, so it’s not looking like widespread adoption of Flexbox in Internet Explorer will be happening anytime soon, but never say never!  And regardless of that, it is now finally a good time to start use Flexbox on mobile devices!

If you’d like to learn more about using and implementing Flexbox, here are two links from Chris Coyier of CSS-Tricks:

Creativity: A Matter of Taste

What’s the #1 quality attributed to designers? Creativity. A creative director literally manages creatives… in the creative department. This isn’t just organizational, it’s procedural. For instance, Lean UX promotes design studio activities in which participants create dozens of rapid-fire sketches. Those outbursts of creativity are great, but what’s rarely discussed is taste level. I feel that good taste is as important as anyone’s ability to brainstorm. Here are some elements of taste for consideration in your designs.

Creativity: A Matter of Taste1. Aesthetics. Visual design and branding are more than creative colors and custom layouts. Studies have linked visual design to users’ perceptions of usability and credibility. The better a visual design, the more users will trust it. Good designers track trends (without impersonating them) and avoid anachronisms.

2. Simplicity. Feature sets grow bloated because teams want to add value to products. It’s much harder to explain what you didn’t do. However, creativity isn’t just about new functions and use cases. It’s about ingenuity in combining and reducing those features. For example, which sounds like a more tasteful checkout UX: a 1-click button, or pop-up ads and pre-marked checkboxes for email newsletters? When I’ve worked on the latter, they always tested poorly.

3. Social customs. Users want ethical, safe experiences. No-nos include vulgarity, invasion of privacy, and moral affronts. For instance, Google Glass is a cutting-edge technology that’s sometimes misunderstood as a 24/7 surveillance tool. Rightly or wrongly, social judgments affect purchasing decisions.

4. Metaphors. Designers often map features to a UI metaphor to leverage users’ mental models. Caution is warranted for metaphors that may look contrived or tacky. As a simple example, horizontal tab UI mimicking file folders is easily understood. But occasionally designers position their tabs perpendicular to the page to be unique. Reading sideways labels is a creative UX, but in a not-so-good way.

5. Accessibility. Small web fonts aren’t sexy, they’re hard to read. Green and red buttons for positive and negative actions? About 5% of the population can’t distinguish them. Sometimes designers fall in love with visuals; I’ve been guilty of this many times. However, it’s poor taste to trumpet a beautiful design at the expense of those who can’t use it.

I hope these ideas are useful not only for designers, but any project member who defines, reviews or implements design. Do you have additions to this list? Please feel free to add a comment.

Posted in Design, Musings, UX

Are Devices Personal?

Every day I get “targeted” emails from retailers that are designed to appeal to my personal profile and preferences. Much of the content is driven by search history, browsing patterns, shopping cart contents and the assembled profile that the retailer has created for me. Which is great in theory. I want more relevant experiences that are tailored to my unique needs and interests. However, the reality is that my profile is actually an amalgamation of my entire family. You see, when I get home at the end of the day, my phone, my laptop, and my tablet become public property. My wife and my kids each take their turn and have their own experiences online. Experiences that include, disney princesses, monster trucks, cake decorating and yoga. So now when I get an email from a retailer, it is typically reflecting a diverse set of browsing experiences. For instance, the other day I got an email from Amazon that was promoting a set of jungle gym related products (a rock climbing wall, gymnastic rings, a play tunnel, etc..). From that, I could tell that my wife was thinking about remodeling our play room. To which I replied, “you are not turning our playroom into jungle gym.” Helpful for me, but perhaps not the intended goal of the email campaign.

Targeted Email Campaign

Targeted Email Campaign

So while personalization is becoming more engrained into a variety of web experiences, some of the methods need to be re-evaluated. It is not safe to assume that devices are personal. They can easily be shared and frequently represent a group of users. Therefore, the challenge is for retailers to focus on a personalization model that supports individual interactions vs. broader profiles. This can be achieved by looking at the context of the interaction to understand the intent, mindset and ultimately the needs of the individual user. Only then can personalization become truly personal.

STLUX Recap: Getting Started with Website Performance

Back again with another recap of the STLUX conference sessions!  My previous post in this series covered Practical Interaction Design for Developers, a session by David Ortinau.  Where that session discussed how developers can educate themselves about user actions and expectations in regards to the design, this session covers another aspect of a user’s expectations for your site: its performance.  Given by Duncan Jimbo, here are my notes from Getting Started with Website Performance.

What is website performance?

Website performance is the delay perceived by a user between an action and a response.  Your website’s performance is your business, because poor performance costs you money.

Nearly 60% of users expect a site to load in 3 seconds or less, and 71% of mobile users expect the same results or faster than its desktop counterpart. Read the rest of this post »

STLUX Recap: Practical Interaction Design for Developers

St. Louis had a user experience conference last month (yes, I am very timely) called STLUX, and I’m starting a series of blog posts to recap some of the sessions I attended.  Instead of the typical essay type of blog post, these will be a more in depth breakdown of my notes, which come in a bulleted format.  Enjoy!

It is the duty of the machines and developers to understand people and how they think. We can absorb the pain, so our users have a better experience.This is the first in the series, covering the session by David Ortinau called “Practical Interaction Design for Developers.”

  • Interaction design is defined as the structure, behavior and the meaningful relationships between people and products.
  • In interaction design, people are the focus, not the code.
  • EVERYONE (on the team) needs to be informed about what the design is trying to do.  Designers and developers need to work together.
  • Developers don’t know everything, and should constantly be questioning themselves and their solutions.
  • “How did I come up with this answer?” Question yourself. Your brain can often trick you with your first answer.
  • It is the duty of the machines and developers to understand people and how they think. We can absorb the pain, so our users have a better experience.
  • Bill Verplank’s Three Questions (for interaction designers to answer in regards to their users)
    • How do you do?
      • Push that button
    • How do you feel?
      • I messed up
    • How do you know?
      • Way finding
  • Don’t make your user figure out and understand how your product’s system works.  Your system should understand how your user thinks and expects the system to work, and your system should work accordingly.
  • Slow is a bug
  • Cognitive dissonance is a bug 
  • Cognitive dissonance is when the user expects one thing to happen, and something else happens instead.

All in all it was a great presentation.  I always enjoy listening to David speak, because he has a fantastic presence and passion for the topics he presents.

Stay tuned for my next session summary on fixing your website’s performance!

The Dynamic Customer

At the recent Adobe Summit in Salt Lake City, one of the most interesting presentations I saw was delivered by John Bollen of MGM resorts. As the Chief Digital Officer for MGM, John is responsible for supporting the guest experience through technology. During his presentation, John brought up an interesting challenge. At MGM, they realize that their guests are never the same guest twice. What that means, is that a single customer might visit an MGM resort multiple times under different circumstances. For example, they may visit on an outing with their friends, then again on a business trip with colleagues, and later on a leisure trip with their family. The key to delivering a great experience for each visit, is understanding which mode a guest is in, and providing the appropriate interactions. 

The challenge John described is what I refer to as The Dynamic Customer. While you may have a good understanding of your customer’s needs, behavior and motivation, you can’t expect them to engage with you in the same way every time. Customers are people. And people are dynamic. They are emotional, sometimes irrational and largely influenced by their environment. To provide the right experience at the right time, you need to take into consideration the customer mindset and provide interactions that are appropriate for the situation.

Take for instance, my experience with our local drugstore. I always seem to find myself running to the store with my kids to pick-up a gallon milk, a prescription, or whatever last minute item I need. However, when I have a sick child with me, the last thing I want to do is get them unbuckled, drag them into the store and then try to get them back into the car. On one such visit earlier this year, I was going to the drugstore to buy some Motrin for my son, who was with me in the car. I thought, wouldn’t it be great if I could just get the medicine that I needed through the pharmacy drive-thru window? Surely that makes perfect sense. So I tried to do exactly that. Unfortunately, my store did not offer any OTC medicine through the pharmacy window. Needless to say, I was not a happy customer that day. The drugstore did not consider my situation and provide an appropriate experience. On the other hand, all of their other customers did get to experience a sick, screaming child being carried through their store…

In this instance, it seems that my situation was not unique. The drugstore has recently added some of the most common over-the-counter medicines to drive-thru pharmacy window, including children’s Motrin. Now they’re thinking about The Dynamic Customer, and so should you.