The front-end of an application or dashboard can be difficult to design. It takes a multi-disciplinary perspective to get right and often requires different people since it's not common to find a single person that has the skills and experience. Getting this wrong results in applications that have cluttered and complex views, undiscoverable functionality, and require a steep learning curve. At one point or another we've all been in the situation where we feel overwhelmed by an interface. The interface demands that we learn about it instead of it unfolding itself as we would expect. This cognitive overload interrupts the flow which we're currently in and may have serious implications. The extreme example would be: imagine you're driving down the highway at 80mph and you had to determine what type of brake you needed to use before you could press the brake pedal. That situation could be catastrophic. Fortunately, most situations aren't as time sensitive. However, with a growing number of applications we're using in the Cloud, these applications will need to understand that they can no longer demand large cognitive loads and steep learning curves. If something is hard to use, people will just decide not to use it. When we build applications or dashboards, we use the process below which mixes the disciplines of:
Let's dig a little further to learn why these cycles are important.  Define the roles for the view In order to build a view that isn't cluttered and complex, we need to understand where the user is coming from and what they would understand. We look for vocabulary, models, and visual language in order to speak the language that the user speaks and decrease the learning curve for the user. Given that we're building new software it's safe to assume that the user has a problem which needs to be solved. This problem is often in the form of creating visibility in a system. For example, in an invoicing system a user might want to determine: "Which are the vendors which haven't invoiced their work?" In a marketing web site an analytics questions might be, "Which users downloaded a white paper and have an expired trial product for more than 15 days?" For a dashboard the question might be, "What is the state of the business given the target goals?" Of course, these questions lead to other questions which is how applications are born. For example, "Once I have the list of users for which the expired trial software, I would like to send them an coupon discount offer via email." If you're familiar with the idea of a user story from XP/Agile, this is where you might realize that a user story encompasses the type of user, what they want to see or do, and the reason. Data organization and analysis Most software does something with data - store data, move data, process it to determine interesting relationships, and/or visualize the data to identify some insight. The bad news is that data is often stored in different places and encoded in different structures or formats. The challenge of answering specific and interesting questions about data usually requires merging and visualizing multiple data sources. The question that arises next is, "If we have different data sources we'd like to join, how often do we need to make that happen?" Some applications/dashboards require real-time updates while others might be monthly updates. This makes a huge different when determining the technology required to enable the data management/storage. View layout and interaction Let's consider two contrasting situations which require two different type of attention: Divided Attention Situation: You're driving down the highway going 45 mph and you see a billboard. The billboard has a picture and maybe some text in huge font size. Sustained Attention Situation: You're sitting at a coffee shop reading your favorite financial analysis magazine. The magazine is full of three column small-font text articles which surround graphs and charts supporting the text. These two situations point out that the users or consumers of your application have an inherent context which needs to be considered. The speed in which they expect to consume the data/tool. The amount of time they are willing (or able) to invest in the tool to answer whatever question they're need to answer. The type of attention (i.e. sustained, selective, alternating, or divided) they are willing (or able) to engage. Another important area to consider when thinking about layout is how relevant or important data is relative to each other. For example, for a dashboard, you might place the aggregate results at the top of the page while having the detailed breakdowns as expanding sections below. The expanding interaction helps keep the entire page clean while still serving the potentially smaller number of users/consumers which need the really fine detail. Of course, if you determine that most of your users needed the detail, you would define the layout different and determine which of the details were most important. The bottom line There's more data and more questions than we, as knowledge workers, know how to deal with at once. By understanding the context of our role, what questions are most important to our success, what data we have access to, we can determine how to build a view (or interface) which helps us find insight or become more productive. If you have some tough questions and lot's of data, let us know by registering for a free Cloud Analysis Consultation. We love interesting problems! Add Comment node.js, the Cloud, and The Mobile Device 08/08/2011
node.js, The Overview node.js is a very interesting use of JavaScript. Think of it as a JavaScript host which enables you to create non-blocking code which can be very fast due to (among other reasons) it's ability to scale. Why is non-blocking code interesting/useful? In a world of parallel and distributed computing, blocking code is like inserting sand into your car's gear-box. It makes everything grind to a halt while wasting energy. Node.js takes this asynchronous (non-blocking) model of programming and exposes resources as services. For example, you can open a TCP port or handle HTTP requests using a node.js service through a very simple snippet of JavaScript. Take a look at http://www.nodejs.org/ for some great resources on how to do this. There are a number of Cloud Service Providers which are offering node.js hosts which will enable you to expose a node.js service to the internet. Of course, you can always host it either on your own server or a virtual machine, but by using the Cloud you won't need to manage your own infrastructure. Some Cloud Providers and community support for Node.js: Heroku: http://devcenter.heroku.com/articles/node-js Joyent: http://www.joyentcloud.com/products/smart-appliances/node-js-smartmachine/ Windows Azure (Steve Marx shows how to use node.js on Windows Azure in his Mix11 session): http://channel9.msdn.com/Events/MIX/MIX11/SVC04 Amazon Web Services: https://github.com/raincloud/node-aws node.js and Mobile Devices HP/Palm is taking a very interesting approach and using node.js inside their mobile device. Traditionally, it would be insane to run a server on a mobile device given the power constraints on a mobile device. With WebOS, HP/Palm are enabling us to create node.js services on the device and are exposing some of the WebOS functionality through node.js services. As shown in the figure below, the 'Client Code' which is running on the device can depend on a node.js service that is also running on the device. This on-device node.js service is guaranteed to be available since there is no need for a network call. It can be thought of as a middle-tier service which can determine what to do given the state of the network. If the device is connected to the network, this service can reach out to other services located in the cloud. If the device is *not* connected to the network or low on battery (or whatever other reason determined by the on-device node.js service), it can choose to use the local resources. Since WebOS implements some operating system calls (i.e. local I/O to files) using node.js, the on-device node.js service can call these WebOS specific services.  For more information about the WebOS implementation of node.js see http://developer.palm.com/content/api/dev-guide/js-services/overview.html#javascript-for-services. Also check out this talk given by HP/Palm (discussed node.js at ~21:00) http://www.youtube.com/watch?v=gB1TNwSRI6U Whether it's an implementation of node.js or some other way of exposing asynchronous (non-blocking) services on a mobile device, this is a very interesting convention that is here for the long haul and will allow us to create better applications more quickly. Corensic, You Rock! 08/25/2010
As a software consulting company that strives to connect people through software, we love working with customers that are forward thinking not only on the technology front, but also in the scenarios we enable which connect people in interesting ways. The combination is both powerful and simply fun. Corensic asked us to design and build a web site that was more than a presence- more like a marketing central nervous system. As Prashant Sridharan describes in his posthttp://www.corensic.com/CorensicBlog/tabid/101/EntryId/13/A-Website-Story.aspx, we built this central nervous system by bringing together ASP.NET, Amazon Web Services (Amazon EC2,Amazon S3, Amazon CloudFront, Amazon Flexible Payment Service), Optify, Salesforce, Jigsaw, and Mailchimp. Much credit is due to Prashant for driving the content/requirements and continually setting the vision for this project. It has been a pleasure to work together and congratulations on a successful launch of Jinx v1! Check out the Corensic web site at http://www.corensic.com. ASP.NET with Amazon Web Services: Petboard 03/10/2010
ekeepo LLC had the pleasure of building and delivering a sample ASP.NET application for the Amazon Web Services team which uses Amazon S3 and Amazon SimpleDB as a backend for the application. If you’re a Windows/ASP.NET Developer and are trying to figure out what the cloud means for you, download this sample. The opportunity is significant and it’s really simple to get started. One of my favorite parts of this sample is a ASP.NET Membership implementation using SimpleDB as the backend. Yes, simple concept/idea, but just pretty cool. Grab the bits at: http://developer.amazonwebservices.com/connect/entry.jspa?externalID=3592 Enjoy! After watching (http://www.ted.com/talks/daniel_kahneman_the_riddle_of_experience_vs_memory.html) Daniel Kahneman, I couldn’t help and wonder about how experience and memory impacts my world of Project Management and Business. To summarize the talk (which I highly recommend you watch), we have two independent perspectives, the now (experience) and the past (memory), which we use as a measure for a series of feelings. In other words, we feel stuff as a result of both: what is happening now and what happened in the past. What complicates things is that we quickly forget what happened a few minutes ago and are left with the memory which is a subset of the actual event. It may seem at first like this is splitting hairs, but when I started to think about this from the perspective of teams working together I saw a conflict that arises in business and projects. Goals in projects are often written in the form of “when we’re done with this project we have (insert result here).” These types of goals are written from the ‘memory’ perspective and are results or event oriented. For example, the goal ‘Acquire 3 new customers this month’ says nothing about day 14 of the month and what needs to be done that day to succeed per the defined goal. As Mike Cohn writes (http://blog.mountaingoatsoftware.com/advantages-of-the-as-a-user-i-want-user-story-template) a user story in Agile Software Development is often in the form of “As a <type of user>, I want to <some goal> so that <some reason>”. Both these models are great, they just don’t consider the experience perspective of getting to the result. On the other hand, the experience perspective is very relevant to the person accomplishing the goal. It’s what makes every day ‘fun’ and has a huge impact on how we spend our time. I’m a huge believer that if something isn’t fun (or at least worth the effort), it’s probably not sustainable. Kahneman doesn’t make any assertions as to the right amount of experience or memory. He merely states that we should consider both. In software projects, if we omit either of these perspectives we’re doomed. If we’re not satisfying the business objectives or memory perspective, we lose the funding and the reason to solve interesting problems. If we’re not satisfying the experience perspective, we lose the great people that are working on the project who care about interesting problems. Agile solves this challenge by, on the memory side, defining user stories, and on the experience side, providing the time in a sprint/iteration to implement the functionality to enable a set of user stories. This provides an operating model for the team to implement the user stories. The solution architecture provides the operating environment for the user stories. Both the operating model and the operating environment provide infrastructure for a better experience for the team which increases the probability of a successful project. Last year I had the opportunity to work with the Team Foundation Server team at Microsoft to author the Agile Engineering Practices which are delivered on MSDN as part of the Team Foundation Server 2010 product: ‘MSF for Agile Software Development 5.0‘. These engineering practices provide a bridge between the TFS2010 tools (TFS Source Control, Team Foundation Build, and Microsoft Test and Lab Manager), the TFS documentation which provide scenario based details on how to use the tools, and some of the concepts in agile software development. It was a pleasure and fantastic opportunity to work with folks in the TFS User Education and TFS Engineering teams. It’s great to finally see the work illuminated by the bright lights! For more information on each of the engineering practice sections visit: Build and Deploy Continuously Branch Stratgically Test Early and Often VSTS, Work Items, and Visualizations 09/21/2009
Visual Studio Team System (VSTS) brings together a number of dimensions and perspectives which help software teams manage collaborative magic. This infrastructure allows the team make software and not worry about some of the mundane details that are hard to track using traditional collaboration tools (ie. spreadsheets, emails, documents). For example, most projects which deliver value to customers end up lasting some amount of time. Over that time, lots of bugs are found and hopefully fixed before they impact the customer. Team Foundation Server (TFS) Work Item Tracking (WIT) helps manage the state of each of these bugs. These Bugs (capital B, the work items) have a state model definition which allows team members move the bugs through states (ie. active, fixed, fixed ready, fixed verified, etc…). Similar to Bugs, there are other artifact types that need to be managed throughout the project- for example, user stories, requirements, and risks with their own defined state model. This state model for a work item type allows the team to query for work items which are in a particular state. This is super powerful both at the detailed and time-aggregate level (ie. cumulative flow diagrams which show number of work items over a date range). Michel Perfetti has posted a very useful work item control (http://tfsworkflowcontrol.codeplex.com/) which shows a visualization of work item state transitions over time. This is a very good example of how visualization of the dimensions managed by VSTS can help software teams. Another example of a visualization is the branch management in VSTS 2010 Beta 1 (http://msdn.microsoft.com/en-us/library/dd405662%28VS.100%29.aspx,http://msdn.microsoft.com/en-us/library/dd465202%28VS.100%29.aspx). It’s very exciting to start seeing more of these visualizations that bubble-up the power of the integration provided by VSTS! I expect to see more in the future. Using AWS Public Data Sets 06/12/2009
Download Package: http://ekeepo.s3.amazonaws.com/Census Public Data Sets Walk Through Package.zip I wrote a step-by-step walk through (with screenshots) which shows how to use the Year 2000 Census Public Data Set in the context of AWS services (Amazon EC2, Amazon SimpleDB, and Amazon Simple Queue Service (Amazon SQS)). The following are the scenarios which show the use of Public Data Sets to solve some business problems:
| ArchivesAugust 2010 Categories© 2011 ekeepo LLC |
RSS Feed