Piece of Mind: On web development, UX, social media, etc.

Posts in category Usability

Strength in Software

Jan03
2015 Written by Hany Elemary

“You cannot be anything you want to be — but you can be a lot more of who you already are.” — Tom Rath, Strength Finder 2.0.

A while back, I was sipping a macchiato with my friend Julio at a local coffee shop when we started having one of our typical thought-provoking conversations. I told him I really liked the quote (above) from Strength Finder, and that I found it eye opening and rather refreshing.

We tend to focus on improving our areas of weakness. Though we often forget that we might be naturally limited in certain areas and, thus, might not improve as much as we would like to, regardless of how much work we put in. And that’s ok … at least it should be. Strength Finder focuses on finding talents that make individuals unique, then nurturing those talents.

“Well, this can also apply to software.” Said Julio. Then he followed up by explaining how software companies often focus their efforts on their software’s weaknesses while forgetting the features or architecture that sets their software apart. After hearing this mapping to software, I immediately started thinking of companies that do this well. Here is the list I could come up with.

Google:

Even though they’re now a major player in many areas, Google will always be a “search” company first. What they’ve done to improve searching is quite remarkable. Google, however, was never about fancy UI design, even though they have very capable engineers. Instead, they realized their users’ goal was to get to the results/content as fast as machinably possible without anything getting in the way. That alone was/is one of the main differentiators between Google and it’s early/current competitors. Here are some interesting features Google implemented to improve its search engine.

  • Instant Search: Tying users’ search query to a dynamic result set.
  • Mobile-friendliness: Indicating whether a site is mobile-friendly or not when users are searching on Google using their mobile device.

Apple:

As opposed to Google, Apple has been a software company that excels at aesthetics and design. Captivating, simple designs and interactions are evident in every Apple product. Apple has never been about early innovation or first-to-market. They always considered existing products and made them dead-simple to use. That’s their true innovation and they have stayed true to their software strength and culture.

  • iPod: It wasn’t the first music/mp3 player, but it changed the music industry.
  • iPhone: It wasn’t the first smartphone, but it revolutionized the market.
  • iPad: It wasn’t the first tablet, but it was the one that created a new market.

Facebook:

What makes facebook different from other social networking apps is their dedication to the social graph and connecting people in many ways.

  • Graph search: A natural way of searching. “Restaurants in London my friends have been to.”
  • Timeline: A new way of looking at your social history on Facebook.

Microsoft:

Microsoft didn’t do as good a job as the other companies until recently. They led the pack in Operating Systems (Windows) and utility tools (Office). For a while, things seemed to have gotten a little stale at Microsoft until their recent cloud-based solutions (Office 365). But the point remains. They stayed true to their software’s strength.

Conclusion:

As we all get a little introspective around the new year, perhaps it’s time to think about the features we introduce in our products. Perhaps we should constantly put them under the microscope. We should stay true to what makes our software strong, by resisting any temptations to add features that take us away from the “ONE” path that our software does better than anyone else’s.

So what are your software’s strengths?

Posted in General, Social Media, UX Design

API Design: Simplicity

Dec13
2014 Written by Hany Elemary

Designing APIs is no walk in the park. In many instances, when your API becomes popular, it can be difficult or even impossible to change. Whether it’s a programming language or framework, a good API makes a world of difference for developers who use it.

Needless to say, an API needs to be simple. But what’s equally (or more) important is for an API to be simple to get started with. The point is, you need to have a low barrier to entry for new users. jQuery, as opposed to other JavaScript frameworks, does a fantastic job of allowing new developers to, not only become immediately productive with the framework, but also get excited about JavaScript development in general.

However, when not accompanied with good design principles, simplicity may lead to anti-patterns. For instance, the main strength of jQuery is perhaps one of its major weaknesses. The “kitchen sink” jQuery’s overloaded main method violates the single-responsibility principle of API design. It also violates another characteristic of good APIs; Self-documentation, though I’ll write a separate post on that at a later time. Consider the following use of jQuery’s main method below:

$(selector); //A string containing a selector expression. 

$(element); //A DOM element to wrap in a jQuery object. 

$(html); //A string defining a single, standalone, HTML element. 

$(elementArray); //A DOM elements array to wrap in a jQuery object. 

$(object); //A plain object to wrap in a jQuery object. 

$(jQuery object); //An existing jQuery object to clone. 

$(callback); //The function to execute when the DOM is ready.

Obviously this function has multiple, vastly different responsibilities at this point. So, it’s best to actually separate out the responsibilities into different, self-documenting functions. And while jQuery appears to be overloading the function, it actually isn’t as there is no inherent overloading in JavaScript. After taking a deeper dive into the source code of jQuery, what’s actually happening is that jQuery is validating the arguments/parameters of the $(argument); call to determine which execution path to take. Here is what’s happening in (simplified) pseudo-code:

  • If argument is a “string”, then
    • check if argument is a selector and execute path
    • check if argument is html (regex) and execute path
  • If argument is an HTML Node, then execute path to wrap in jQuery object.
  • If argument is a function, then the “callback” path is taken for DOMReady.

This obviously increases the complexity of the code due to the presence of different execution paths. Thus, the maintainability of the code becomes a problem. Additionally, this impacts testing negatively as there are 7 different scenarios that could go wrong within the same function as opposed to one and only one. It is no surprise that jQuery has one of the highest cyclomatic complexity measures of most JavaScript frameworks out there. See image below (less is better).


Cyclomatic Complexity Chart for Popular JavaScript Frameworks

Martin Fowler criticizes jQuery’s seemingly overloaded API for getters/setters for similar reasons.

The act of retrieving data is fundamentally different to that of setting a value, so the names should be more clearly different.

Martin Fowler.

While it appears simple to use the same method name for two different behaviors, there are some negative implications in terms of using the API and maintaining it.

Posted in API, Frameworks, General, Web Development - Tagged , , , , ,

Accessible pagination with ARIA

Apr13
2014 Written by Hany Elemary

Using native HTML elements has positive effects on web content accessibility. Elements can be read properly by screen readers according to their function or role. For instance, a button written using the markup below will be announced as: “Refresh Button” by screen readers.

<button id="refresh">Refresh</button>

Nice and easy. However, web development isn’t always this straight forward. We often need to write more complex widgets using a combination of native elements. And in some cases, we use frameworks to tap into well-defined/designed patterns to fulfill this need. That’s largely due to the deficient nature of the HTML spec. But can you imagine for a second a richer HTML standard? A standard encompassing all the well-established widgets that we’ve been inventing, re-inventing and using for years?

Let’s consider a paging toolbar widget … I imagine a markup (in its simplest form) to be something like this:

<pagingtoolbar numPages="10" recsPerPage="10" totalRecords="100"/>

Obviously this is a simple case. There are certainly more complex use cases for paging toolbars. But the point is, we have been using this pattern for years, yet HTML hasn’t caught up to provide an API for it. So, since the example above doesn’t exist in the HTML standard, we use frameworks such as Bootstrap or Foundation or we roll our own. A common markup for pagination is one that Bootstrap provides:

<ul class="pagination">
	<li><a href="#">&laquo;</a></li>
	<li><a href="#">1</a></li>
	<li><a href="#">2</a></li>
	<li><a href="#">3</a></li>
	<li><a href="#">4</a></li>
	<li><a href="#">5</a></li>
	<li><a href="#">&raquo;</a></li>
</ul>

There is nothing wrong with this markup. In fact, it’s perfectly valid, and well-structured. Now, let’s consider how it will be announced by screen readers (VoiceOver on my Mac):

Link. Left pointing double arrow.
List 7 items
Link 1
Link 2
Link 3
…

Screen reader users will gather the context by the time screen reader announces the 5th or 6th line (Link 2 or Link3). The context is gathered by the way things are ordered and where objects are located in the DOM. But wouldn’t it be better if we can announce the context as soon as the user lands on the pagination widget itself?

Here is an example of how one might improve on Bootstrap’s pagination widget:

<nav role="menu" aria-label="Pagination">
   <ul class="pagination">
      <li><a href="#">«</a></li>
      <li><a href="#">1</a></li>
      <li><a href="#">2</a></li>
      <li><a href="#">3</a></li>
        ...
   </ul>
</nav>

Pagination menu bar
List 7 items
Link 1
Link 2
Link 3
…

Now, the widget name/type is announced immediately, making the context much more understandable for screen reader users. This immediate announcement happens because we’re using ARIA (Accessible Rich Internet Application) roles and labels. The ARIA standard helps developers provide additional context to composite/complex widgets and can describe the various states (disabled, checked, busy, etc.) on these widgets.

We can improve this widget even further by introducing a few tweaks. The full, improved markup for this widget can be found here

Following the ARIA spec is instrumental in making web applications more accessible. For more information on ARIA, visit the W3C website

Posted in Accessibility, API, Frameworks, General, UX Design, Web Development - Tagged , , , ,

Content First Design by Example

Mar09
2014 Written by Hany Elemary

It is not uncommon for developers to start marking up their webpages immediately after receiving visual mocks from designers. What this does, however, is that it robs everyone (developers, designers and product analysts) from understanding the content before it goes live. In fact, it’s rather surprising how a lot of organizations, big and small, don’t have a good grasp on their content and it’s semantics. This lack of understanding can lead to a bunch of serious problems:

  • Illogical organization and flow of the data on the User Interface (UI).
  • Incomplete implementations and, thus, maintainability issues.
  • Invalid markup, which leads to accessibility and/or search engine visibility problems.

These problems are costly in terms of time and money.  So, how can they be avoided? The answer is to design your content, just like you design other parts of your application. What needs to be done as the first step is to examine your content. Users come to your web application for one thing and one thing only; to consume and interact with YOUR content. It would be ill-advised to not examine this content and design “it.”

So, in a nutshell, content-first design is an exercise that allows us to interrogate the content to better understand:

  • The most important piece(s) of data
  • The priority of each piece of data in relationship to others
  • The logical grouping of data to form meaningful objects
  • The various workflows/scenarios in which the priority might change (does the workflow change when accessing the content on mobile devices vs. desktop?)

Consider the UI mock of a typical search results and filters application (see below):

Search Results Application Mock

The user got to this page as a result of some search query (from within the app, from a search engine, etc). It’s not at all uncommon for developers to code this mock in the following manner:

<!doctype html>
<html>
   <head>...</head>
   <body>
      //banner
      <section id="filters">
         <h1>Filters</h1>
         <form>
            <input type="checkbox">...
         </form> 
      </section>
      <section id="search-results">
          ...
      </section>
   </body>
</html>

If you’re a developer, stop here for a second and ask yourself if you would have written a similar implementation. Be honest!

Now, while this HTML implementation is perfectly valid, it isn’t at all ideal. The main reason for this page’s existence is the search results. Shouldn’t this content (search results section) be front and center? Shouldn’t it come first in the source order? The answer is yes, it should. The filters complement the main content (search results) and, thus, should come next in the source order. So in order for the code to be more semantic, the filters and search results section need to be flipped in order.

As suggested previously, content-first design allows you to question the priority of the data and interrogate the content in a way that can reveal patterns and relationships. The exercise will aid in writing more semantic code and, hence, better visibility/accessibility to screen readers and search engines.

For ideas on how content-first design workshops might be conducted, watch this presentation.

Posted in Accessibility, Responsive Web Design, UX Design, Web Development - Tagged , , ,

Why web accessibility is not exciting

Mar06
2014 Written by Hany Elemary

While web accessibility usually carries a specific meaning (accessibility given certain disabilities), I typically think of it in the true sense of the word; making software accessible to as many people, user agents, devices, and machines as possible. To me, accessibility is a design problem that needs to be solved. A problem that isn’t separate from the rest of any application’s architecture. A problem that needs to be approached properly, and planned for thoroughly.

Unfortunately, the reality in which we approach accessibility is a little bit different. I was stumped by one of my colleagues who asked me:

“I hear you talk constantly about accessibility, but man, it’s such a boring topic. Do you really dig it?”

The answer is obvious … I’m blogging about it. So, yes, I dig it. But what was most interesting about his statement is that I actually agreed with him. Let me explain. My colleague’s statement made me realize how poorly, us, web developers approach accessibility. It is, unfortunately, thought of as a task or checklist that gets tacked on at the end to be “compliant” or to fulfill some requirement. How can this not be boring?

But it’s not more boring than writing your unit tests after you’ve implemented your functionality, whatever it might be. It is the same concept. Test driven development (TDD) is fun when you follow its principles; letting your tests guide your design and development of better code. If you do it last, then you’re just fulfilling some “silly” requirement while not reaping the benefit of the approach.

Accessible web applications are not happy accidents. They are a direct result of good engineering principles and solid design put together. They’re based on deliberate and intentional design. So, to produce quality, accessible web apps, we need to change our perspective.

How do we do that? How do we become more empathetic to users with disabilities? I’m glad you asked.

“You don’t need to change peoples’ mind about disabilities, you need to change their minds about themselves.” – Music within.

I love this quote from the movie music within. It reframes the approach to promoting better accessibility practices. We need to start changing the way we think and develop web applications. We need to approach the problem a bit differently. Here are some thoughts:

Before development:

  • Content-first Design: Understanding the content, it’s priority in the document, the relationship of this content to other companion content, and the grouping of content to form meaningful objects is content design. Additionally, being aware of the various medium and workflows the content might be consumed is important to understanding how your content might be tailored and delivered to varying audiences. For more info on the topic, watch this presentation on how content-first design workshops might be conducted.

Beginning of development:

  • Progressive enhancement: Starting really simple is the key to having a maintainable and logical web application. For instance, rather than laying out the styles while developing the page, write the flat markup first and see if it makes sense. Progressive enhancement suggests starting from simplicity and then layering in enhancements for more capable user agents.

During development:

  • Semantic markup: divs have no semantic meaning. There might be some other tags that provide better semantics. For instance, use the html5 header tag for grouping outlined headings or for your site’s header. Use the section tag for logical sections in your page. Here is a link to an HTML5 element flowchart.
  • ARIA roles: ARIA – Accessible Rich Internet Applications is a spec that helps provide better context to screen readers of rich web apps. ARIA uses landmark roles to describe certain portions of the page. For instance, developers can specify that a header tag is used as a “banner” using ARIA role=“banner.” This aids non-sighted users in quickly understanding the context of the section and, hence, the layout of the page.
  • ARIA roles also have other atomic values for widgets such as sliders, toolbars, menus and menu items. These are helpful when writing a UI framework.

After development:

  • Test your application using a variety of different tools. There is a bunch of automated accessibility tools out there that can help.
    • TotalValidator
    • AChecker
    • Juicy Studio Accessibility Toolbar.
  • Finally, put your site to the test. Learn how to use VoiceOver (a screen reader software) if you’re on a Mac or the Accessibility mode if you’re on Windows. There is also a Chrome screen reader plugin by Google called ChromeVox.
  • Last but not least, test the usability of your web application with non-sighted users if at all possible.

I hope to elaborate on the different approaches listed above in future posts. I just wanted to put some thoughts out there to, hopefully, get others thinking about the topic.

Posted in Accessibility, General, UX Design, Web Development - Tagged , , , ,

Presentation: A humbling experience through web accessibility

Jan09
2014 Written by Hany Elemary

Here is the link to my slide deck on web content accessibility:

A humbling experience through web accessibility

Session Abstract:

“We are sending him on a treasure hunt.” Said Bob Robertson-Boyd, our product analyst, after our accessibility test. “The more cues we can give upfront, the more successful he can navigate around the interface.”

Visually impaired/legally blind folks navigate software in ways most of us, developers, are oblivious to. As a software engineer, watching an accessibility test can humble you pretty quickly. In this session, we will discuss our humbling experience with accessibility at OCLC while working on WorldCat.org and WorldCat for local institutions. We will explore accessibility automation tools and screen readers, discuss best practices to achieve better usability, and uncover accessibility myths and misconceptions. We will also share insight into baking accessibility in the development workflow. Last but not least, developing empathy can only happen when you’re in someone’s shoes (experiencing something first/second hand). So, we will work through live demos of accessible/inaccessible apps.

Posted in Accessibility, Lessons learned, Presentation, UX Design, Web Development - Tagged , ,

Presentation: Responsive Web Design & Collaboration

Feb19
2013 Written by Hany Elemary

Presenters:

Aaron Ganci, User Experience Designer, OCLC
Bob Robertson-Boyd, Senior Product Analyst, OCLC
Hany Elemary, Senior Software Engineer, OCLC

Presentation Description:

OCLC has developed a new Web interface for the FirstSearch product using responsive design techniques. We have previewed this new interface with 19 institutions and in early 2013 we will go into open beta with the thousands of libraries currently subscribing to FirstSearch. We will describe the project from its beginning to the present and share what we have learned throughout the process. The majority of our presentation will focus on the technical aspects of implementing a mission-critical Web interface for desktop, tablet, and mobile devices using HTML5 and CSS3, including how we leveraged this emerging technology to meet the core principles of our business: performance and accessibility.

Discussion points:

  • The importance of understanding your content in order to build the semantic structure of pages and use microformats to extend your reach across the Web.
  • WCAG and ARIA accessibility guidelines within our application.
  • The use of progressive enhancement and CSS3 media queries to design interfaces that fit various device capabilities and viewports.
  • How to support a rich user experience by using CSS3 hardware accelerations, as opposed to JavaScript, to improve transitions and animations.
  • How to off-load data requests to improve performance.

Related Resources:

Posted in Accessibility, Agile, General, Mobile, Presentation, Responsive Web Design, UX Design, Web Development

Discoverability in simple UIs

Jun11
2012 Written by Hany Elemary

“Pity gives way to respect when much more value is delivered than originally expected.” - John Maeda, The Laws of Simplicity.

What a great quote! That’s exactly how I felt a few weeks ago when I helped a friend install Nest in his house. Nest is a classic case of simple design. It is also a great example of a Natural User Interface (NUI). These interfaces encourage users to interact through their simple, seemingly familiar design. For instance, in Nest, there is only one/two input controls; the ring and the clickable screen itself. There is nothing else that gets in the way. The user is not overwhelmed with a bunch of options and, therefore, decisions become more obvious. Watch this 4-minute video on the setup process then read on…

The most interesting part to me was the use of the same input device (the ring) with inherently different UI components.

List Menu:

The ring is used with different list options (Wifi Networks in the video). By rotating the ring, the user is able to step through (highlight) each option in the list.

Input Field:

Another use case for the ring is typing in a text box (password in the video) by selecting letters, numbers and special characters from the screen.

Spinner/Range Fields:

Yet a third use case is applying the ring as a spinner field to loop through a list of numbers to set the zip code. And lastly, the main use case, adjusting the thermostat, is also controlled with the ring. Rotate right for heating and left for cooling, as the interface provides feedback through the temperature in degrees and color codes (orange=heating, blue=cooling).

Design Decision:

The interface highly demonstrates good design decisions. Notice, for instance, how confirming actions are made a bit more explicit by clicking on the screen or the ring. This way, users don’t get frustrated confirming an action they didn’t explicitly make. All other options are made more forgiving by using the ring/wheel.

Conclusion:

When users have a limited set of options, they have no choice but to zero in on those available options and start interacting with them.

“Proportionately more attention shall be paid to that which is made less available.” - John Maeda, The Laws of Simplicity.

By the time users work their way through the first UI control, they’re experts at using the thermostat. Learning one use case means learning a whole set of familiar interactions in this UI.

As designers, we have to remember that each time a user gets introduced to a new option, there is some level of uncertainty. It takes a special designer to cut down on those uncertainties by reducing the options in a way that’s still fully functional and appealing. Now compare Nest my friend’s more familiar-looking, older thermostat.

Older Thermostat

Overwhelmed? I’d like to hear your thoughts.

 

Posted in Accessibility, General, UX Design - Tagged , , ,

As I see it: user feedback

Jun10
2012 Written by Hany Elemary

We can’t ignore our users if we never allow them to introduce features in the first place.

This weekend, a random, strong thought popped in my head. I couldn’t fit it in a twitter post, so I’m starting a new short series of posts called “As I see it.” What triggered this thought is a presentation at “No Fluff Just Stuff” conference in Columbus, Ohio, about UI/UX design and user feedback. The presenter, who shall remain nameless, said “Once you have a stable product, ignore feedback from users as it will only cloud your vision.” Something to that effect anyway … I’m slightly paraphrasing.

While I sort of agree with his statement, to me, it felt like it stood against being empathetic to the user. It also got me thinking that if we change our mental model, we never have to deal with muddy feedback. So here it is: we can’t ignore our users, if we never allow them to introduce features in the first place. Instead, we need to move up the abstraction ladder and ask them what problems they’re trying to solve. Then we (product owners/designers/developers) analyze these problems and introduce solutions in terms of features.

I realize this is easier said than done and that it takes a “master of craft” kind of person to actually train users not to provide feedback in terms of UI changes or features (something that’s engraved in every user of software these days). But the question is: is it possible? Would like to hear your feedback.

Posted in As I see it, General, UX Design, Web Development - Tagged

Book review: Mobile First – By Luke Wroblewski

Feb05
2012 Written by Hany Elemary

I finally got around to reading “Mobile First” by Luke Wroblewski. This book is simply brilliant. It targets a wide spectrum of job descriptions. Developers, designers, product managers/owners, human factors folks, content strategist, and more.

Although native apps (along with their design details) are discussed in the book, the book’s main focus is on the mobile web experience. On that topic, Luke focuses on three main ideas in the book and discusses the design details around them. The ideas are as follows:

  • The inevitable growth of mobile, which leads to new opportunities
  • The constraints of mobile, which lets you focus on content & organization
  • New innovative features that lets you think differently about design

One of my favorite parts in the book is a great analogy made by Rachel Hinman at Nokia that desktop is like “diving” while mobile is “snorkling.” Luke takes this analogy and adds further wisdom to it by saying that in both “diving” and “snorkling” you’re looking at fish underwater. Meaning that the core value of your website stays the same regardless of how it’s accessed. “So, don’t deny people access just because they’re on a mobile device.”

There are plenty of good quotes and takeaways from the book. I only included the ones that were really interesting to me. 

Content:

- “There simply isn’t room in a 320×480 pixel screen for elements of questionable value.”

- “Reduction is the best layout approach available to you on mobile.”

- “When interacting with mobile devices, people are in one eyeball one thumb mode.”

- “When it comes to mobile forms, be brutally efficient and trim, trim, trim.”

Design Gotchas:

- When designing for the mobile web experience, it’s very common to include controls/actions at the bottom of the screen. While that’s common due to the fact that people use their thumbs for touch, you have to be careful as to not interfere with the phone’s hardware buttons (back button, search button, home button, menu button, etc).

- Destructive actions such as “cancel” or “delete” should be placed uncomfortably out of reach as to not be mistakenly clicked when using other controls. Also, this makes people think hard about the destructive action they’re about to take.

- Set the user expectation. If you present the user with something that looks swipe-able, it better swipes or else the user will be frustrated.

Closing remarks:

- “The mobile web experience is getting better. Device APIs are being worked on as we speak. This will result in tighter integration between your phone’s hardware and the web browser.”

- “Welcome to mobile where the only thing you can count on is change.” My takeaway here is that we need to design our layout responsively, and adapt accordingly. Also, as Luke suggests, we need to accept that this area will be in constant change (at least for some time) so “prototype, prototype, prototype” to see what’s working and what’s not.

All in all, there is lots of great design details that make up this awesome, easy and engaging read (only 120 pages). It is a “must read” if you’re considering mobile in your company.

 

Posted in Book review, General, Mobile, Responsive Web Design, Web Development
← Older Entries