Rodney is Founder and Chief Architect of InterKnowlogy, established in 1999. His day consists of working with C-Level Fortune 500 and above clients, and technology and interaction design consulting. Rodney has expert knowledge across web and native apps for phone, tablet, and desktop apps, with expertise in scaling with cloud architecture. Rodney has a passion for natural user interface technologies that span touch and gesture, and he leads the design team to create high impact experiences. He has been a MVP Solution Architect and served on Microsoft’s Architecture Advisory board. Rodney has been recognized as one of the top architects in the world with over 25 years of professional experience in creating solutions. He also serves on the InterKnowlogy Executive Team and is involved in the daily operations of the company.
After giving a workshop at Art Center College of Design on Interaction Design in the Enterprise, I had several conversations with students on what companies are expecting from interaction designers. Simply taking a look at interaction design job descriptions from various companies can quickly show the diverse expectations that are out there. Part of the issue I have encountered stems for the raw newness of the field. Its roots lie in graphic design and grew up through web and mobile apps. Job descriptions are often asking for a variety skills that span branding, graphic design, web and/or mobile development, visual UX design, sketch, wire framing, and user research. I have yet to meet a human who I would call an expert at all of these things, but if you are out there please introduce yourself to me because I have a job for you.
I would never ask a developer to do a branding exercise with a customer, but I could imagine the hilarity of the outcome. We would also never ask a developer to design the UX. Developers do not think like users – they think like systems, workflows, services and information. The visual experience a developer would design might look more like a data entry form because it is perceived as efficient. On the other side, we have graphic designers who are skilled on creating beautiful looking UX, but they also do not always think like users. We all have downloaded really cool looking apps that, after using it for a short while, stop using them because they feel clunky and are difficult to use. Of course we all have encountered developers and graphic designers who can think like users, which usually comes from the wisdom associated with building many, many experiences (we love you guys).
So if you do not want to have your app feel like a data entry form, or a beautiful app that no one wants to use, what do you do? This is the space that interaction design fills. This is how we use interaction design:
After a project has been won, features need to be identified. Long gone are those days where features (or for you old timers, requirements) are documented in words. We have learned a long time ago that documents that describe apps quickly become out of date and are difficult to maintain. What is worse is that two people reading the document can have two completely different expectations on what the app will do. That is the best and fastest way to have an unhappy project outcome. So instead of writing documents, we spend most of our time working with various stake holders and listening to their ideas. These are ideas that they have come to us to make real. We facilitate the conversations to draw out the information we need. This is a team effort, and on that team we have an interaction designer. The interaction designer works with the team to crystalize the features, sketch concepts, and facilitate the conversations with the stakeholders. The sketches and storyboards that emerge are created by the interaction designer and then discussed with the stakeholders for validation, and course corrections are made with the pencil (not in code). Feeding the sketches is the wisdom of designing dozens (if not hundreds) of apps across many different industries.
Should the project warrant it, the interaction designer can organize and execute on user testing to validate the early concepts. When does a project need user testing? This is a common question. The truth is that even though you are creating a new app, it might be so familiar that the user is well understood simply because of past experiences. But when the user is not understood, user testing is necessary to maximize your chances of getting the app right the first time. With user testing, feedback is collected and concepts are modified. We use sketches during this to have people focus on the features of the app, and not, for example, on how well the branding is integrated into the app. Transitions and animations can also be important parts to help users understand the app. In this case, the interaction designer can create simulated but guided experiences to allow the user to more deeply experience the app. Depending on the user population and how much energy the customer wants to put into user research, a fully branded simulated experience can be created by the interaction designer.
All of this is to solicit quality feedback before software development actually begins. A quality estimate can be produced because the features have been thoroughly analyzed. Expectations have been managed because the customer has seen the app before it was developed. With this process, we can produce an accurate build schedule and estimate to complete the work.
Once app construction begins, the interaction designer works closely with the graphic designer so that the design can be productionalize into art assets that the developers can use. Typically our graphic designers have more technical expertise than the interaction designer because they are more focused on the pixels and what the target platform can and cannot do. The graphic designer will create static visual comps of the app that are appropriately layered so that the development team can pull out the pieces to be integrated into the app. The production work that goes into building the art assets is extremely tedious and requires detail oriented people, right down to each pixel. Everything is positioned based to the pixel. All colors are defined in hex. Detail after detail, and nothing is left subject to interpretation by the development teams.
Once the app is constructed, it must go through a finalization and usability stage. There are things in design that simply cannot be addressed until the app is constructed. These might be subtle animations to cue the user, or how a list of items responds to a touch gesture, or how one view of the app animates to the next view. You just cannot plan for these things until the app is running and you can see everything in context. Issues can arise from data dependencies and latencies that came about that were unplanned. The interaction designer works with the team to guide final usability modifications to complete the experience.
Even before a project is won, interaction design can be used to echo back early concept conversations to show customers that you are interested in the work, invested in its success, and want to understand more about what needs to be accomplished. This is done with the power of the pencil in sketch. For a customer seeking solutions, nothing is more powerful than seeing an idea come to life in a simple sketch. This quickly builds a level of trust that we would not have otherwise been able to achieve. Interaction design can help you win the work.
I’m hoping that this post has provided some clarity to companies seeking interaction designers and what they should expect from them. Interaction designers are filling a huge hole in many companies. The appropriate use will lead to more successful projects time and time again. With interaction design you can expect that your projects can be more accurately scoped and your customers’ expectations much better managed.
When taking your presence to mobile, there is always a scalability conversation that quickly occurs. This is especially true when the systems you need to access are on-premise. Your on-premise systems may have never been designed for the user load you would add with mobile apps. Additionally, your on-premise systems may not even be exposed to the internet, introducing a whole set of security complexities that need to be solved. In the case of IMSA, we are relying on services already exposed to the internet, so one less set of issues to manage.
- How many users would concurrently be accessing the services through the mobile apps?
- What is the latency for the service calls?
- How much effort is it for the service to generate the data?
- How often are the services taken down for maintenance? For how long?
- Will the services change over time as backend systems change?
These are relatively simple questions, but they serve to shape the approach you take to scale. To provide the best possible mobile experience, we envisioned a brokering capability to be served by Azure. All mobile apps across iOS, Android, and Universal Apps would access this brokering layer for data access. This brokering layer is caching data from IMSA services for fast access.
There is immense flexibility in how you shape solutions in Azure for scale, particularly around caching. Ultimately the purpose of data caching is to minimize the number of trips to the backend services. There can be instances where the backend services are so expensive in time and resources to call that the architecture must do everything possible to minimize the user paying the price of waiting for that call to complete. In this case, Azure can be setup to actively keep its cache fresh and minimize the amount of calls to the backend services. Mobile apps would then always have a fast and fluid experience and never feel slow, and a company would not have to worry about putting a massive amount of resources for scaling up their backend services.
Fortunately, this was not the case for us and the IMSA backend services. The backend services are responsive and data is small per service call. Also, it is not expensive for the backend services to produce the data. Even in this case, there is benefit to leveraging Azure. IMSA race events are at key moments in time, and traffic heavily spikes around each event. It is not beneficial to have hardware laying around mostly idle 90%+ of the time waiting for the spike in usage. Additionally, the IMSA services could be taken down briefly for maintenance. Using Azure for brokering calls still has merit because capability can be scaled up and down around the IMSA events. There will be minimal additional load put on the backend services because Azure is doing most of the work of serving data to the mobile apps.
The approach we took for IMSA relied on a combination of HTTP output caching (via ETag) and Azure Redis Cache all within Azure Mobile Services. Basically, when a mobile app makes a request from an Azure service for the first time, no ETag is present because our services did not already generate it. However, we have the URL and parameters passed in, which forms a unique key to the requested data. Redis cache is checked to see if the data is present. If the data is present and is not expired, then the cached data from Redis is returned. If the data is not present or is expired in Redis, then Azure makes the request into the backend IMSA services, puts the response into the cache, and returns it to the calling mobile app. An ETag is generated with each response, so if the mobile app requests the same data again that ETag is supplied. This is informing our Azure services that the calling mobile app has data already, but is not sure if the data is still valid. The benefit of supplying the ETag is that we can check whether or not the ETag has expired, meaning the related data in cache has expired. If it has not expired, an HTTP 304 is returned which is much lighter weight response than if the cached data was returned.
There is a downside to this approach. When simultaneous requests are made for the exact same data (based on the URL and the parameters passed in) at the exact same moment, each request could do the full trip to the backend IMSA services. If IMSA had millions of users during each event, we would prevent this by doing data locking within Redis, but they do not so the extra engineering to prevent this is not warranted.
Through this technique, we have set ourselves up to be prepared for tens of thousands of new users at each event without bringing the IMSA services to their knees.
While we were busy thinking through the interaction design elements of new IMSA mobile apps, we knew we were going to have to build six apps (iOS, Android, Universal Apps for phone and tablet). The app architecture we chose to follow for this is Model-View-ViewModel (or MVVM). Our mission was to maximize the amount of code sharing across all implementations of the app. The more code sharing we could do, the less code we would have to develop for each platform. Less code means less time to develop and less to test, making the aggressive schedule more achievable.
The Model layer contains the business logic and data that will drive the IMSA app. Data would be served through a scalable cloud infrastructure being constructed for the mobile apps. Regardless of mobile OS, the business logic and data will remain the same. How we access the data in the cloud and retrieve would also remain the same. These layers are devoid of any user interface elements are a logical candidate for re-use across all the mobile operating systems. Perfect – one layer to write one. But we want more.
We were suspicious that the View layer would be so unique across mobile operating systems that the ViewModel layer would not be re-usable. The ViewModel layer is responsible for binding the Model layer (the business logic) to a View (the user interface). Remember we are talking about code sharing across iOS, Android, and Universal Apps – this have to be do so different that writing a consistent and shareable ViewModel layer would not be possible – right? Wrong! After some initial prototyping we were pleasantly surprised. The path we have chosen is going to allow us to use the same code in the ViewModel layer across all operating systems.
From our early calculations, thanks to Visual Studio and Xamarin, we are predicting to see about 75% code re-use (of the non-generated code) across all the implementations! Excellent news for the developers and project manager. We’ll dive into code examples in an upcoming blog, but next we’ll discuss our approach with Azure. Also, this video has additional information for code re-use with Xamarin.
The IMSA Mobile Apps project is currently in flight and we are actively working on building this cross platform/cross OS solution. This article is the first in a series of blogs discussing the details of the project, and we’ll be actively trying to catch up to the current day as we are busy building towards the Laguna Seca race.
Back in the first week of December 2014 we flew out to Florida to visit the IMSA team with Microsoft in Daytona Beach. Microsoft was hosting an Architecture Design Session, or ADS for short, to flesh out features of the solution. It became quickly apparent that the solution was layered and complex. Many features discussed have become part of longer product roadmap as IMSA is committed to providing the best experience possible to their fans. Also, it should be noted as in all ideation sessions, some ideas discussed are put deep down in the feature backlog.
I am certain that some would ask why IMSA involved Microsoft. This is a mobile app – what does Microsoft know about building mobile apps across iOS and Android? Well, it turns out quite a lot. From past projects, we already knew the tooling we get with Visual Studio and Xamarin allows us to build amazing mobile apps across all platforms and OS’s. The other side of the coin is the plumbing we get to integrate into cloud infrastructure. This app needed to scale across the huge IMSA fan base during live events. From past projects we knew how effective we could be building scalable mobile apps with Azure. So to IMSA and to us, involving Microsoft made perfect sense.
In the ADS, some of the interesting features starting popping up:
The app would need to change shape depending on whether or not a race is live or not. We thought treating the app almost like the NFL Now app would be interesting. There could be something interesting always to watch on our app, regardless if an event is live or not.
IMSA radio is a live audio stream. The app would need to deliver this feed just like other integrated audio content on your device. So turning on IMSA radio, putting your headphones on, and then your device in your pocket should be as natural as playing music.
Using the device’s GPS, if the race fan is at the event the app should respond differently than if the person were elsewhere. When you are at an event, what you are interested in is different than when you are not.
Telemetry information from the cars. It would be just awesome to watch your favorite car at the event or at home and see all the g-forces they are pulling when they are flying around the corners.
IMSA services to content and structured information are not scalability to a mobile play. A cloud infrastructure would need to be placed in front of the IMSA services so content could be cached and served more quickly.
After the ADS we went home and decomposed all the features while looking at the schedule. We needed to pick a race event to target deployment. We had a lot of homework to determine our approach. In this next blog we will be discussing how we were planning on maximizing code re-use across all platforms and OS’s.
There are more smart phones in China than there are people in the United States. These are the kinds of factoids that are shared when talking about mobile strategy to spur conversations about why it is imperative for your company to “go mobile”. Mobility has been a consumer driven movement and not the enterprise. Many years ago before iPhones and iPads, Microsoft produced extremely weak and laughable mobility offerings into business. Windows was not lean and mean, and it ate batteries for breakfast. Apps that ran on Windows consumed resources left and right, sucking up memory and constantly banging on your hard drive. These devices were barely functional – they could run everything on the Microsoft platform, but barely and for not long unplugged. It couldn’t be adopted by business because it just didn’t work.
Fast forward a few years. Hardware and software is different and better. Apple has made touch phones and tablets fun and intuitive, and now expectations on how to interact with devices and apps have been elevated. Everyone is connected and has their collective noses planted into their favorite devices. Consumer centric services have emerged as tens of thousands of apps and have grown through Internet standards (email, web, RSS, etc.). Businesses refactored software they already made for the web to mobile apps to try to prevent competitors from getting a leg up. And now, these devices that we’ve grown quite fond of are carried right into the workplace.
Now that each employee is carrying smart phones and/or tablets into work, these devices are trying to be used for business productivity. There has been no displeasure from CIO’s about this – who wouldn’t be satisfied with their employees buying their own equipment with a constant flow of free hardware refreshes. Portable access to email and web are fantastic, but is this what we are now calling business productivity? Your phones and tablets have an unlimited supply of consumer apps, but really how are these devices helping me be more productive and a better worker? Each business is very different, and although email and web access is the lowest common dominator, making better workers requires smarter business apps. These are the apps we use every day in laptop/desktop form, and until today they have been relegated to these larger devices.
Hardware has become cheaper, better, and smaller despite Microsoft. Business is still running on Windows, and this is not changing anytime soon. Have you seen how many IBM mainframes are still being licensed? It is not because business loves big iron – they have made too much investment in these systems to make switching platforms a ridiculous proposition. The same is true about people’s desktops and laptops. So when your next hardware refresh comes, and it runs Windows 7 or 8, the form factor is very likely to be that of a tablet. You might still wish to carry your personal device that cannot be locked down and secured on your business network, but over time as more consumer centric tablet apps become available on Windows, there be less reason to do so. Everything we do on our big desktops or laptops will run on a tablet. We will have our smart business apps with us at all times, plus Angry Birds. This is why Microsoft, the turtle in this race, has hope.
Thought I’d share the latest architectural diagram we created for the TSRI Collaborative Molecular Environment WPF application: