Excellent article from Stacey Higginbotham at Gigaom:
As folks increasingly store and access information online, the data centers powering cloud services need to be managed more like a single computing entity rather than a bunch of servers, according to a Google white paper (Google calls it a mini-book) released today.
Check out the article.
You may be interested in the following related posts:
{ 0 comments }
A few weeks ago I evaluated a randomly selected dashboard using Stephen Few’s 13 Common Mistakes in Dashboard Design. Today, I have picked another Dashboard, this one from VisualCalc, a web-based analysis software provider.
Purpose of Dashboard:
The Swine Flu Dashboard tracks the daily progression of the H1N1 Flu (Swine Flu) virus on both a country-by-country and U.S. state-by-state basis. This public dashboard tracks both laboratory-confirmed cases and deaths resulting from the virus. The Swine Flu Dashboard contains four graphical indicators, each focused on a different aspect of the virus:
- Total laboratory-confirmed cases and deaths on a country-by-country basis.
- Total laboratory-confirmed and probable cases and deaths on a state-by-state basis within the U.S.
- Cumulative global laboratory-confirmed cases on a day-by-day basis, broken out by country.
- Overall composition of the different types of flu’s tested within the United States.
Description via VisualCalc Press Release
click to expand
Pass
Something powerful happens when things are seen together. Seeing everything at once is an advantage. The Analyze button does take you to a screen where you can dive deeper into the data. This is well done.
Partial Fail
Measures of what’s currently going on rarely do well in isolation. It is more valuable to include comparison, whether the result is good or bad, how good or bad, are we on track, are we doing better than in the past, or better than the forecast. In the bottom right graph, there is a comparison between last week and year-to-date providing some context. That said, most of the data is provided without context. The lack of labeling makes the context particularly hard to determine.
Pass
It appears that the appropriate precision is being used.
Partial Pass
For a measure to be meaningful, we must know what is being measured. A measure is deficient if it isn’t the one that most clearly and efficiently communicates the meaning that the dashboard viewer should discern. It appears that the measures are appropriately picked. Again, clearer labeling would clarify this some.
Fail
I think in several cases the wrong display media was chosen.
Fail
I think this is the weakest area of this dashboard. In general, the data is either unlabeled or poorly labeled. Examples include:
Mostly Fail
The scaling of the top two graphs is quite poor. The scale of deaths to the number of cases is so small, putting them on the same graph (right) or using two axes (left) makes interpretation of the pattern hard to discern. I had spent some time with this visualization pondering how Mexican deaths could be higher than the incidence. The use had 27 deaths compared to almost 14,000 cases, having the marking about 1/3 up the US graph is misleading. In Mexico, there were 106 deaths compared to 5,600 cases. Mexico had almost 1/3 of the incidence, but almost 5 times the deaths. This can be represented better by either having two side-by-side bar graphs or by using a bullet graph, where the portion of the incidence is shaded in the bar. The deaths are such a small percentage of the total occurance, more attention needed to be paid to representing this clearly. On the right, the death data does not even turn up.
Partial Pass
There is a lot of meaty information here, and the graphs seem broken up even into reasonable analysis categories. I think if other problems were fixed, it would be easier to see that the data is arranged well.
Pass
I don’t not get the feeling that the graphing methods were haphazardly chosen. I suspect that tool limitations restricted chosing the right graph medium for the data.
Fail
When you look at a dashboard, your eyes should immediately be drawn to the information that is most important. In this design, everything is visually prominant, and consequently nothing stands out.
Pass
There is not a lot of distracting and useless decoration. There is a lot of screen real estate that is not used for conveying information.
Partial Fail
While the coloring is not distracting as it is in many displays, the color also has absolutely no meaning within the dashboard. I wanted to group all the green, red and blue data in some relative way. I went through the graphs trying to see if all of the green related to the same thing. Better media choices would have alleviated this confusion.
Pass
I think the display is clean and attractive.
There is much that could be fixed in this dashboard if our goal is the communication of information from which people could make decisions.
Please let me know your comments.
You may be interested in the following related posts:
{ 0 comments }
These are all challenges on any data warehouse development project or for that matter on any project I have been involved with. After close to 12 years helping organizations’ of all shapes and sizes develop and implement a data warehouse, I have found one issue or flaw that keeps the project from getting full organizational buy-in: inadequate end user(s) or functional user(s) input during the planning and development stages of the project. We always wait until the last phase of the project “reporting” to allow them to tell us what the reports should look like and what data they currently have. Why not ask them “what data do you need, but don’t have?” or “how can we make your job easier through data and reporting?” My thought is simple we should take a “bottoms-up” rather than a “tops-down” approach for Data Warehouse development and implementation.
One of the best resources for insuring the success of any project is the people using what you are building. So why wait until the end – let’s have them drive the project. When we get to the implementation stage, we will have users banging on the door to get in versus us forcing it done their throats. There’s probably a group of people already in your organization who will volunteer to help design the system and evaluate it. Think of these people as Power User(s).
Finding the best power user(s) requires a little effort. The following list should help you identify, inspire, and make best use of the Power User(s) in your organization:
Power User(s) work side-by-side with regular users – the same people you’re trying to reach with your data warehouse project. If your Power User(s) are excited about the data warehouse, you can be sure they’ll let their colleagues know and that excitement can be contagious. Power User(s) are also vital to testing. They can help you identify potential problems and areas of improvement you may not have found on your own.
You will need the managers of the functional area in the organization to suggest candidates. Do not, however, let managers pick the Power User(s) for you. Their idea of what may make a good Power User may not match yours or the projects.
Power User(s) should represent a good cross section of the organizations workforce. I suggest avoiding employees that have been at the organization less than a year, while they can offer you outside experience, they could slow down your efforts by providing too much basic information about the organization.
Power User(s) do not need to have advanced computer skills already. In fact, having advanced computer skills may be a disadvantage. Advanced users may not help you identify problems less experienced users would see. Technical skills can be taught; the ability to speak for and to others cannot.
Even if you don’t use managers as a Power User, try to keep them involved in the process. The more involved they are, the more excited they will be about the deployment, and the more they will work to make sure it’s a success. Ask them to nominate Power User(s) and to check in regularly with the users. This helps managers see the success of the project. It will also help motivate the Power User(s), since they will see their boss is invested in the project.
Ideally, you want one at least Power User per functional area. Of course, the number of users needed varies by organization. In a very large organization, you may want a couple of Power Users per functional area.
You may be interested in the following related posts:
{ 0 comments }
Amit Agarwal wrote an informative post a few weeks ago regarding Web 3.0. In his post, he links to 4 presentations that do a great job explaining what Web 3.0 is. I have pulled a few of the better slides below.
Make sure you check out Amit Agarwal for the full presentations.
You may be interested in the following related posts:
{ 1 comment }
An InnovaTech Blog
Copyright 2009 - 2006, InnovaTech, Inc.
All Rights Reserved.
Ask Edward TufteError: Feed has a error or is not valid
