Now before you flip to the next post, consider these impressions of past trends when they were just emerging ideas: how many people were wrong about the demand for computers you could actually take with you (laptops), or that people might want a phone that could send a message (smartphones).

During my research I came across this article, which clearly didn’t raise too many eyebrows when it came to light in March but may be a harbinger of things to come: New York Times: Apple Hires Wearable Computing Engineer.

Apple’s ability to deliver innovative products, paired with a leader in an emerging technology should certainly raise eyebrows. Only time will tell if this acquisition, like Google buying a small firm called Android back in 2005, will lead to a related product launch. There’s no doubt, though, that skyrocketing smartphone adoption since 2007 indicates a strong desire for information when people want it and regardless of where they are.

For user experience designers the takeaway is obvious: we need to be thinking about electronic channels that are here and now, but also those that are on the horizon or can reasonably be expected. Structured information, and the user experiences that make it available, must be optimized given the capabilities and limitations of the devices used to access them.

Content Management Systems (CMS) have many different touch points: the physical servers, the server software, connections between servers, the Internet pipe to the user, and the end users’ computers are all involved. Any number of these could be a potential trouble area if there are issues. There are a number of fantastic tools to help isolate bottlenecks, and anyone involved in using, deploying, or maintaining a Web site should be aware of them because it will just make life easier. When a user is looking at a Web page in the browser, sometimes it’s not obvious where the issue is coming from. It’s easy to immediately point at some code on some server somewhere, but what if it’s not that simple?

While some colleagues and I were attending the Sitecore Dreamcore conference in April, several tools were discussed which got me thinking about day to day tools no CMS or Web developer should be without. Some of these were tools I often take for granted, and still others came up that I didn’t even know about. Of course if you’re working in ASP.NET you can debug in Visual Studio, but what about before you even get to that level? What’s actually happening over the pipe or in the Web browser for instance?

Firebug for Firefox

Firebug is a critical tool for any Web developer in my mind. This is an extension for Mozilla Firefox, and has proved to be the tool all others are beginning to be compared against. It features comprehensive tools for looking at network traffic, in-memory DOM states, live page changes, source code inspection, a robust JavaScript Debugger and profiler, console output, and Cascading Style Sheet (CSS) evaluation and inspection. If you haven’t used Firebug in your Web development, you’re seriously missing out.

• http://getfirebug.com

Firebug Lite

Use Firebug in any browser with Firebug Lite, a pure JavaScript solution. For Sitecore projects, I always forget that Sitecore ships with Firebug Lite out of the box. It’s actually amazing to me how close to the full Firebug tool the Firebug Lite tool has come. You can even apply Firebug Lite to just about any Web page on the Internet using a handy bookmarklet.

• http://getfirebug.com/firebuglite

Safari Web Inspector

At the Sitecore conference Derek Roberti also reminded us about the Safari Web Inspector. Like Firebug, it features tools to inspect the DOM of the page and the time between requests and responses on the server — an important way to look at HTTP traffic if you’re looking at performance bottlenecks. One example he used noted was if the Media Library was performing badly while generating media from the database — those requests would be slow while everything else would be fine. Interesting.  Keep in mind that as a WebKit-based browser, a version of the inspector ships with Google Chrome as well.

• http://webkit.org/blog/197/web-inspector-redesign/

Fiddler Web Debugger

Another tool, which I believe originally came out of Microsoft, is the Fiddler Web Debugger. Much like the Safari Web Inspector, Firebug will evaluate HTTP traffic requests, headers, and responses. But Fiddler does a whole lot more. It will record and even replay requests.

• http://www.fiddler2.com/fiddler2/

Charles Web Proxy

A personal favorite of mine is the Charles Web Proxy, which is cross platform and is another HTTP inspector. You really can’t go wrong with sniffing HTTP traffic and I think it’s critical to have at least one tool like these in your arsenal.

• http://www.charlesproxy.com/

.Net Reflector

This tool is exceptionally handy for any ASP.Net developer as it will de-compile and inspect any .Net based DLL to see all built-in objects, their methods and properties in a searchable, drill-down UI. I’ve used it to do things as simple as locate exceptions in third-party code, but obviously it could be used for much, much more.

• http://www.red-gate.com/products/reflector/

Server-Side Tools

Of course Sitecore and other CMS tools are mostly server-based and so no toolset would be complete without some great server-side monitoring tools.

Wireshark

This is an Open Source tool which looks and inspects just about every single protocol request made against servers.

• http://www.wireshark.org/

AVICode

This is an exceptionally robust server-based agent which monitors all ASP.Net Web requests on a Web server or group of servers. It can monitor all DB connections, SQL statements, call stacks, exceptions, requests, and responses in real time, providing HTTP payload information and query data as it’s happening. This monitors a live server while your public is actually using your application, live, in real time. Their toolkit even goes as far as injecting a small snippet of unobtrusive JavaScript in responses to performance monitor request and response times, AJAX data, and catch error conditions and the code which generated the errors on the client.

• http://www.avicode.com/

Dynatrace

Finally, another suite of tools which apparently was discussed at the Velocity Conference a few weeks ago was the Dynatrace product suite, which seems similar to AVICode in many ways. They however have a free offering that sounds more along the lines of Firebug for debugging Ajax requests.

• http://ajax.dynatrace.com/

And the List Goes On

Obviously there are server, network, and performance monitoring tools galore around these days. These were just a small list of ones I’ve been thinking about. Others on the client side include MSIE’s Developer Tools (getting a major facelift in IE9) and Opera’s DragonFly. You could spend all day looking for tools and not getting any actual debugging done: More than 440 tools are listed here in a number of categories.

• http://www.softwareqatest.com/qatweb1.html

Happy debugging!

No single administration is going to be able to digest and re-write all the information sharing rules. But a single administration can make a dent in the long-term problem by providing a better level of IT services to their constituents, which include all government agencies, particularly those interested in information sharing at the unclassified and controlled unclassified levels. The Office of the Director of National Intelligence’s Intelink unclassified network is a good example of an information sharing space that is Web accessible and includes a secure Web-based email, which is a must-have for international workers.

Building this level of service for the whole of government would take time, resources, and research. To increase user adoption, usability and policy concerns would need to be addressed. It’s a lot of work to be done. But trying to address network, application development, and information quality from the highest level of government I fear is going to leave little impact on the main problem: the network is as stove piped as are bureaucratic procedures of individual departments and agencies. We need to find a way to support horizontal information sharing within our government so we can solve problems without escalating everything to the highest levels and waiting for the decision to trickle down.

Application development and information quality are important issues that need to be addressed. But if the government provided a stable platform-as-service equally to all government agencies at the unclassified or controlled unclassified level, agencies could free up resources to tackle the information quality issue by hiring the necessary subject matter experts to make those data quality decisions.

Having an information sharing network for the whole of government would also impact the way government relates to contractors. Contractors should have clear and consistent technical requirements and procedures for accessing government networks, hosting Web applications, and delivering code and other raw files. As it stands, many contractors are left befuddled by the process or crunched by timelines and end up hosting applications on the public Web that would better be hosted on an intranet environment. When contractors are left to handle Web hosting, they often find themselves forced to pull the plug on a given Web site or application because the funds have run out on a given project and no one has quite figured out how to handle a Web site as a deliverable for archiving.

The big picture is that we, our government, needs a safe space and method for sharing data internally. And the horror stories about what would happen if people could share information transparently with each other haven’t really come to fruition. The Internet is a great model for what people can organize when they are free to organize themselves. Rather than worry about the exact process, our government should give itself the platform it needs to pull together and work together on issues we all care about and concerns we share. We are capable of sorting out the details. What we need is an accessible but secure information sharing space that will allow the whole of government to seed solutions from one administration to the next.

In late May I attended a Web Content Mavens event in DC on the topic of planning a mobile site or mobile app. One of the panelists Peter Barclay, Managing Director of Vaya Mobile, described three main use cases for mobile apps, which may help answer this question from the end user’s perspective.

The first scenario to consider is whether there are any past user behaviors you can effectively transfer from a different environment into the mobile platform. Here you need to specifically look at past user behaviors that can be used to predict future behaviors or past behaviors that are likely to be repeated frequently. The Pandora app is a great example:  it streams music through the app based on previous music searches and ratings. Pandora had been a popular web application for some years before its mobile app was introduced. Mobile banking apps are another example of past-behavior-based apps: People have been checking account balance, paying bills, and transferring money at bank branches or on the web for years.  Now with mobile banking apps, they can make these transactions on their phones as well.

Citi Mobile for Smartphones

The second scenario to consider is whether your users can receive personalized content and service through the mobile channel. Both Facebook and LinkedIn apps evolved from the Web platform to the mobile platform leveraging user profile information that the social networks already had. Have you ever ‘bumped’ someone with your phone? The popular Bump app allows two people to exchange their contact information and photos by simply bumping their phone together.  This app certainly has made the change-number process a lot easier and more fun.

The third scenario to think about is whether you can deliver any location based content or service via a mobile app. When people are on the go, they need things immediate and nearby — mobile platform has a native advantage providing geo based information. Apps like Yelp (local business reviews) and Flixster (movie show times) leverage smartphone’s GPS capabilities in their features.  Another app called SeeClickFix lets citizens report and track issues such as potholes, graffiti, idling cars, and broken traffic lights in their neighborhood. Now with a smart phone, people can submit reports and upload pictures when they come across a problem and every report can be directly seen by the public as well as offices responsible for fixing the issue.

Importantly these three use cases are generalized scenarios that can help you evaluate whether a mobile app is right for you and the users you want to connect.  If a mobile app design fits two or three of these use cases, it simply shows a stronger business case for your organization to take on the initiative. Certainly beside these scenarios, if anyone has any other thoughts about use cases or has any other comments, please feel free to share them.

I’ve spent the last week and a half trying to bring myself up to being capable of following along with the class on the first day. All of my years of Web application programming and the dozen scripting languages I’ve touched over the years did not prepare me for Objective-C. This is different. Harder? More complex? Probably, but I don’t know enough about it yet to answer those questions .

I picked up two books from The Pragmatic Bookshelf to get a leg up. While I’m not all the way through them, I can confidently say that they have been helpful:

• Beginning Mac Programming: Develop with Objective-C and Cocoa by Tim Isted
• iPhone SDK Development by Bill Dudney and Chris Adamson

I’ll let you know how it goes.

As a faithful BBC News reader (and an information architecture nerd), I appreciate the BBC being so communicative about their design choices. Too often I go to a Web site I’ve visited before only to find things have changed, with no mention of it. I stumble around trying to reorient and I start second-guessing myself: did they really change the Web site or am I just misremembering things again?

I’m not sure how many non-design-focused BBC readers read the preliminary discussion of changes before they were apparent, but I was impressed with the BBC’s efforts. It convinced me to buy into their changes, and I actually got excited about seeing the changes go live. This was a nice contrast to the usual feeling of disorientation I feel when I go to a Web site that has changed everything on me overnight.

The BBC’s discussion of design changes includes great visuals. You could see mock-ups of the changes before they were made to the live site. And it’s always entertaining to see how a Web site has changed over time. When the changes went live, a video was posted to quickly explain them.

Realizing that the BBC is a highly visible, highly trafficked Web site in the business of news and funded by the UK taxpayer, there still seem to be lessons for any organization undergoing a redesign in communicating to users (not just internal stakeholders) about design changes and the decisions behind them.

Of course, from the perspective of a Web design firm – the ability to integrate and display all of your social content in one location and to aggregate that of your friends is hugely important. Cliqset comes with a REST API interface, a translation proxy, and can be done via a stream for real time communication. Another step has been taken in the rush to community organization.

When I previously worked for an online education company, we created specific user testing to help determine if the lesson interface should scroll. For this user test, we created two prototypes of the user interface. The first prototype displayed the lesson in a paginated method and the other prototype displayed the lesson in one scrolling page.  In the end, both methods were desired by the user for two different scenarios. The scrolling interface was preferred when the task was “reviewing of the content” and the paginated view when their task was “first time learning” of the content. The scrolling page allowed for quicker searching and scanning of the content, while the paginated view offered a less overwhelming experience for initial ingestion of the content.  I recently saw a similar dual interface on Dell’s website for configuring a new computer.  The default view is the paginated view where the content is “chunked” into pages and the second view is a one page scrolling view.  The paginated view provides a less overwhelming experience for a user who does not often configure a computer, while a one page view is appropriate for a user who has previously configured a computer.  The one page view also supports a “review” scenario for someone who uses the paginated view, but might want to review their configuration at anytime.

On another recent project I observed user testing where a few users were more negative to scrolling than the other users.  Clearly the less web-savvy users were more averse to scrolling than the more experienced users, but another user preferred non-scrolling not because they were less savvy, but because their favorite website did not scroll. This user was not conditioned to scroll to find content.  In the early days of the AOL interface, users were conditioned in a similar way.  AOL catered to an audience that was not web-savvy and took great effort in not scrolling their pages which resulted in other content presentation side effects and challenges.  In the end they conditioned their users on how content was accessed.

Similar to conditioning user behavior, you can create expectations of a non-scrolling interface with the initial presentation of the content. If the content is presented tightly within the screen view, it will give the user a sense that there is nothing else to view.  Jared Spool speaks to this topic in his blog.

Controlled scroll areas within a page is another variation of the scrolling challenge. At times a controlled scroll area is the best solution for secondary content.  At times it is better to retain “context” between primary and secondary content and the controlled scroll area support this. Another acceptable controlled scroll area scenario is when all the content does not initially need to be seen and it is expected the user has enough motivation to scroll to find the additional content. In this case a controlled scroll area is also appropriate.  In both of these cases, a controlled scroll area can help solve page real estate challenges.  If you use iTunes, you can see controlled scroll areas used often.  When iTunes uses these scroll areas, they are accomplishing two things, they are minimizing potential information overload and also provide access to deep content without forcing the user to navigation away from the page or push other related content out of context.

The idea that important content should be displayed above the fold is still relevant, but because all users and content are not the same and the users continue to evolve their online behaviors, the scrolling effect will continue to be a design decision to carefully consider especially as new online platforms and user interfaces are designed.  Don’t fall into the trap of jamming all your content above the fold and then create a larger usability problem. It is important not to blindly follow a simple rule that applies to all scenarios.  Realize that there is a difference between scrolling 2 pages verses 5 pages. It is also important to appreciate the difference between scrolling through organized content verses disorganized content.  Also, sometimes controlled scroll areas within a page are appropriate. Who the user is and what the content is, are still the most important factors in determining the design solution for scrolling.

Related Reading
Blasting the Myth of the Fold
Changes in Web Usability
Life Below 600px (the Fold)

While many of the early visions of a fully digital healthcare economy are still to be realized, some health organizations are finding success in pursuing a small set of focused, tactical objectives rather than attempting more comprehensive and ambitious strategies sometimes characterized as “boil the ocean” approaches. The best results seem to follow when new Web-based applications / functionality are deployed carefully and incrementally in phases that are closely tied to the individual organization’s ability to metabolize such change.  This approach will certainly leave some important aspirations pushed out till much later on the timeline. However, it does streamline the crucial process of internal socialization necessary for adequate funding and broad-based institutional acceptance.

There are three Web tactics we see driving significant ROI for healthcare organizations. The first is focusing on demand-generation, or using the Web platform as a customer acquisition tool. The second tactic is focusing on patient retention through access to quality information and self-service convenience tools. And the third tactic focuses on using the Web as a platform to promote physician alignment and loyalty. If the appetite and urgency is sufficiently high, some healthcare organizations will move forward simultaneously with aspects of all three tactics.

Demand-generation is perhaps the most obvious role for the healthcare Web, but it also the most frequently misunderstood.  The most crucial step in any online marketing initiative is to understand the metrics by which success will be measured. In demand-generation, the key measurement should not be hits or page views, but rather the rate at which site visitors are driven through a lead-generation flow and converted to contacts or prospects. Another crucial indicator of user engagement and a precondition for conversion is the frequency of times that the visitor returns to the provider site or shares it with others through email, social networks, etc. The conversion is not compete till that visitor has provided contact information, registered to receive outbound communications, or made an appointment for service. The more compelling and efficient the lead-generation flow, the higher the percentage of visitors who convert to prospective patients. So the obvious question is what will drive users most efficiently and effectively through the healthcare lead funnel?

In our research around patient behavior online, we see a significant majority of prospective patients for healthcare services begin their search, not by looking for a provider such as a hospital or a clinic; rather they begin with condition-based research. This fact has prompted many healthcare providers to offer original or syndicated content organized by condition or disease. It has also prompted many of the leading providers to rethink the way they structure their site, converting more to a user-centric model and away from the organizational-centric model. Only after prospective patients are comfortable with the provider’s qualifications in regard to a condition/disease will they initiate contact with the provider. The implications for hospitals and other providers to now create and managing vast repositories of frequently-changing content are significant from both the technology and staffing perspective and must be incorporated in overall governance planning.

Patient retention frequently has more to do with physician relationships and treatment outcomes than the Web, per se, but increasingly research shows that online self-services can be an important competitive differentiator among alternative service providers.  The Web can be an important vehicle for improving patient service through convenient access to patient education information and the self-service tools that cement patient loyalty. Many times the needs of patients are simple, obvious, and frequently overlooked (or buried) on the Web site. Patients ask for help in getting directions, finding parking, making or confirming an appointment, continuing their education, connecting with a support group, etc. Structuring Web platforms to prioritize access to such information not only increases the perceived level of control that patients want, it also reduces the need for expensive call-center support. A second tier of patient support includes making available through the Web various business applications for more sophisticated customer relationship management including, access to electronic health records, direct access to physicians and other clinical staff, business account, pharmacy, etc.

Physicians remain the keystone of the healthcare system and providers are increasingly focused on physician relationship management to increase physician loyalty and the patient volumes they drive. To date, approaches to physician alignment initiatives have focused on two discrete areas. The first is comprised of a series of applications that streamline physician-hospital interactions such as access clinical systems for lab, pharmacy, radiology, etc. The second is a set of tools that focus on practice management. In many cases, the physicians are reluctant to embrace Web-based tools either from a general discomfort with interactive technologies, or because they fear such tools will not immediately deliver the promised improvements in productivity or time-savings. A crucial part of winning the physician audience depends on first enabling the practice’s office manager and administrative staff with the training to provide proactive physician support. In the physician sphere, slow, thoughtful, change supported by robust training and administrative support can gradually improve the efficiency and profitability of small or large practices, gradually turning protestors into promoters.

For more information, check out our SlideShare presentation:

At NavigationArts, we have had the privilege to work with a diverse set of healthcare clients. Please contact us if you would like further information about our specialized healthcare sector service offerings.

1. Web Strategy
2. Strategy to Presentation Layer Design (Information Architecture and Visual Design)
3. Strategy to Technology  Implementation
4. End to End Integrated Web-Enabled Solutions

Regardless of the scope of engagement, User Experience should be at the foundation of every project.  User Experience Design (UXD) is based on Architecture, Interaction Design, Visual Design, Technology and Content Strategy.  Because this work inherently is conducted across several disciplines and often incorporates members from multiple teams (such as the NavigationArts’ team in conjunction with client teams), it is imperative to have repeatable, traceable, and auditable processes as well as best practices in place.  Incorporating best practices into these disciplines ensures that you can reconcile business goals, platform constraints and user needs in order to create a UXD that is valuable, credible, scalable and maintainable.

One of my daily, evangelical discussions is around requirements gathering. In my opinion, it is vital to get all disciplines involved up front, whenever possible, in order to gather the business, functional, and technical requirements for a project.  The value of engaging in this type of task early is to set the foundation/expectation for delivering appropriate solutions.  Realistically, this may not be a possibility for all projects for many reasons; however, it is a critical success factor.

While understanding the limitations of each project (scope, budget, and time) is essential and sometimes non-negotiable, projects can slip off track for several reasons.  It is significantly important to leverage efficiencies and to practice strong Project Management. Planning, communication and partnering are important skills for every team member.  Our approach incorporates industry standard project life cycle phases ranging from Research and Analysis to Maintenance and Support.  Each phase has guidelines around services, tasks and deliverables that help keep the projects on target, within budget and within schedule.  In addition, it is important to employ a strong change management process that is informed by project management and ensures transparency of our work.

The main objective of following a well thought out and effectively communicated process is a successful project.  Inherently, everyone wants this objective but sometimes, it’s very difficult to practice and implement detailed process and best practices in projects that are tightly scoped and scheduled.  For this reason, it is essential to follow a Project Plan, understand the tasks that are not only involved in each phase of the project but also inform the final deliverables.  This is a best practice at NavigationArts, and thus, a repeatable, traceable, and auditable  process becomes a reality.

See my previous blogs on Integrated Solutions: Part 1 – Architects of the User Experience and Part 2 – Why User Experience Design is Important