UXCAST: DataGrid or should it be Data Visualization.

image

I am working on a secret squirrel application. Can’t say much suffice to say I had a situation where a bunch of clients connect to a network – like most apps I guess.

In this situation, I needed to inject a listening app to the overall network in that it needed to keep a pulse check on how the clients within the network are doing. This listening application needed to show the information in a meaningful way but at the same time; I do not want to have to inspect every single one of them each time they connect/disconnect.

I needed to visually show the connection states but I wanted it to be more reactive to me vs. me reactive to it.

Armed with problems like this, I now draw your attention to my biggest pet hate – DataGrids. A developer and you know who you are – would often take a situation like this and go "Ok, got it, what we need is a datagrid and the columns show machine name, state and blah blah metadata – easy peasy!!"

If you are that developer, I want you to do me a favor, remove yourself from the screen design team as you are hereby in a time-out.

Again, the problem is that I want to have a sense of all things are ok but I want to be alerted when things are not. I want to put this UI onto a large screen and just let it sit there keeping an eye on things and the moment something’s amiss – tell me!

Here is what I came up with. It is a hexagonal grid, each tile represents a new client connection and what it does is when a client activates it pulsates (the tile also gets added randomly in the grid). Yes, it pulsates but slowly, so it gives the impression that the "grid" (i.e. network grid) is breathing just like an organic machine.

When something bad happens, the tile flips to a red alert state and if there is a massive network outage the entire screen flickers with red pulsating tiles all yelling "help me, help me".

If more than 10x tiles fail an overall, alert text flows over the top giving you the old "Warning will Robinson, warning" alert.

The point here is simple. I could of easily just taking a data grid and view model, bound the two together and walked away. I actively choose not to do that as it’s a case of thinking about the problem creatively and trying an approach that makes sense but at the same time underpins an important principle – We work with software. We shouldn’t just use software"

That’s why I hate datagrids.

Related Posts:

  • That’s exactly what you do in science when you want to get an idea about a huge amount of data. You abstract the data to visual states. I quite often use heat maps (e.g. Silverligth TreeMap control do those kind of things. In your case you constantly monitoring and you added some dynamic to the control, but it’s still the idea of heat maps. And I agree, its much better than plain DataGrid.

  • One more thing. You could add some kind of grouping/filtering by client connection properties (e.g. ip address range) to your tile panel. If multiple connections starting to fail it would help to visually look for correlations between connection properties and failures. You could even do this automatically with some statistic analysis running in the background.

    Just an idea 💡

  • @ bitdisaster:
    There’s more to this UI than you see. I had to strip it right back for IP reasons, but yes it gets more complex in its composition. In that say you have 50 clients the grid gets bigger, the more you add the smaller the tiles get and so on…

    They also can then break off to geographic shapes to indicate country of origion and so on. Its a fun medium to code & design for me especially given its 100% solo so far on both the dev and design decisions 😀 (Which is partially dangerous as i have a warped mind)

  • Scott Barnes wrote:

    They also can then break off to geographic shapes to indicate country of origion and so on.

    Yeah that was what I’m talking about.

    Its a fun medium to code & design for me especially given its 100% solo so far on both the dev and design decisions (Which is partially dangerous as i have a warped mind)

    Looks good so far!

  • Fallon Massey

    I LOVE it!

    I used to do scientific data visualization, and the level of abstraction would go to the actual physical process, i.e. instead of graphs and charts, you see the physical process you’re actually studying, and the effect of changing variables.

    Well it was a big step up from charts and graphs that you would have to correlate, and beat the crap out of those guys throwing a million numbers at management.

    Not hard to figure out who got the money to do this stuff(on SGI machines at the time).

  • Scott – sorry, I strayed from the initial “how do you like my hexagonal grid” question…

    I would nix the pulsing, it’s too visually distracting for my taste. As a reference example, my car’s dashboard lights power on only at ignition and then light to alert me to a problem. Constant flashing/pulsing is like a Navi system that won’t shut up, you just want to turn it off. Though I could live with shades of color (or ‘colour’ in the Queen’s english) which indicate the current performance level.

    Also I’ll assume this is homogeneous system? If not, then will representing node uniqueness present a layout challenge?

    As for groupings, you then begin to deal with a problem that GIS systems typically encounter – though they refer to groups as ‘layers’. You’ll have to define what’s in the group and how that group is represented – ie. are groups homogeneous and how are they presented if the their content is not?
    Also you’ll have to decide what is the default view level and what are the subsequent levels of detail per layer. In other words, what details show up at what level?

    As to the “randomly added” logic, I worry that random adds create a lot of guess work for the person monitoring the grid because it can hamper their familiarity with consistent trouble spots and add to the chaos when something goes wrong. (As you know, humans process visual cues in a spatial context – ie. I know where the ‘danger lights’ are on my dashboard and where the ‘hey dumbass, get some gas’ light is) This permits me to have an learned reaction to light location.

    Also do you need a rule set which varies by group? For example, you said if ’10x tiles fail then an alert happens’. That rule of thumb may be widely adequate, however it may be possible that a group consists of mainly VPN users, and thus they will be in constant alert phase since VPN will disable network connectivity.

    This brings up notes and actions too. Do you plan to log what actions were taken? This might be important if there are performance levels to achieve. For example smart meter implementations contain penalty terms in the contract. So if a set of meters do not reach a minimum reporting level of 95% a financial penalty can be extracted from the vendor supplying the meter.

    Anyway this is just a bunch of stuff to think about as you move forward – any questions are rhetorical. I do like your general approach though.

  • @ Joe Krajnc:
    RE: Distracting. It’s supposed to be and thats an objective. This screen isn’t something you stare at on a desktop computer, it’s something that goes on a screen in the middle of a room. Its objective is to alert you when a negative action occurs but proceed as normal when everything is aok. The pulsating of the tiles indicate a breathing concept, whereby its movements catch the eye but not to much to warrant a constant stare.

    There is grouping (types of nodes) that provide unique information (small glphys that are shown) – i had to remove them due to IP reasons. Suffice to say the type of node isn’t important given again the only time you want to interact is when a negative occurs post the initial “hey something red is showing jump on it” reaction.

    RE: Random. I had similar concerns but the more i thought about it the more I started to arrive at the conclusion that by keeping the allocation of the tile randomly within the grid is to indicate to the user that the network isn’t so linear in terms of its composition. A node can be online/offline at any given moment and establishing habits of determine where the next node will come online is something I wanted to avoid. The reason is we don’t want the screen to become a focal point of information – it breaks into jail if it does ux wise. Instead we want the screen to be a satellite view of information, basic data indicating basic stateful information.

    Each tile when activated (clicked) either by this UI or an alternative UI can then bring out a more specific view (ie progressive disclosure with layering approaches).

  • @ Scott Barnes:

    I see your point that using randomness highlights/reinforces the fluidity of the network however I’m a fan of heat maps when it comes to large sets of data, so I would hate to lose that by going with random. Maybe it’s just me but heat maps tend to bring some additional visual information on to the picture.

    Ultimately this kind of stuff is a balance between how much information is sufficient to meet the design intent and how much is simply self-indulgent eye candy.