LabKey is getting more of a user community these days, so I thought I'd try something new. This is an open letter to LabKey staff and the community at large, which I hope might spark some discussion about the product.
If you dont know me, I have been working with LabKey for more than 5 years, and managed several big LabKey projects for the University of Wisconsin and OHSU. In addition to writing code and using LabKey in my own research, I spend a lot of time talking/interacting with users who are completely new to LabKey. As someone intimately familiar with LabKey, the latter has been really interesting and eye opening.
LabKey has evolved a lot since I started working with it. It's great to see the recent focus and changes in user experience. The fact that increasing resources being devoted to user experience speaks to the success and maturity of the product. Even with the improvements, I do think there's one big area that's been left behind. In LabKey, the data grid is probably the most fundamental widget that exists. Virtually every application ends up interacting with a grid in some form. The functionality underlying the grid is absolute gold. The flexibility to interact with and cut across your data provides us with more benefit than anything else in the product. However, I also have to acknowledge that when any new user sees it (even tech savvy ones), virtually no one understands what to do with it. I spend a lot of time with smart people and the degree to which people dont get it has been a little astounding. I'm plenty guilty in my own apps of saying 'just train them', but I really think the grid needs a re-think. Not only does it do a suboptimal job of showcasing what should be the greatest power of LabKey, it's a major impediment for new users.
I'm writing this now because I understand the grid and customize view are being migrated to Ext4. That's a big undertaking that inherently means the widget is going to be revamped. There a few observations and suggestions I think would be very beneficial to the product's accessibility to new users.
I attached some more detailed suggestions and comments, but here's the highlights:
1) I dont quite understand it, but when I show new users a grid, they never understand any of the capabilities. They dont recognize that you can click column headers (I know...). Equally important, the terms 'Views' and 'Customize View' dont mean anything to people. They simply need to go. The functions customize view provides are hugely important though. Rather than one 'customize view' item on the menu, simply having 'change columns', 'change filters' and 'change sort' (even if all these did was open the existing customize view tab) would be a major improvement in user understanding. It would be understandable, and more quickly direct the user to the action they need.
2) The Views / Charts buttons muddle together two distinct ideas. There's two concepts: 1) change things about the current table (filter/sort/columns), and 2) visualize/chart your data in some other form. All of the options currently presented on these 2 buttons divide on these lines. We should split up the existing items between the two buttons to make it clearer to people.
3) We shouldnt start by dumping all a table with all rows in front of the user and secondarily making them ask a question about the data (ie. filter). I'm pretty guilty of doing this in the apps I write. If you look at how most other sites handle search (take expedia, amazon, ebay or your favorite site), the user typically goes to a page where they are given fields to enter search terms, and only after this to do they load a grid of data. One could imagine that instead of always loading a DataRegion that shows all the rows, when the user first hits it we just expand the filter panel and dont load data yet. We left the user add filters (ie. ask their questions), and only then load. LabKey has a harder problem to solve then any of the websites I list since the types of questions people want to ask are very diverse. That's in contrast to booking a flight, where there's a obvious, predictable set of fields to display to start. One could also imagine we have some table-level basic to control which fields are pre-shown as available filters. This would at least give a way for each table to more rationally define what set of search options a user might want.
The reason I posted this here was to hopefully at least provoke some thought in other LabKey clients/users. As I critique our own applications, I'm coming to the conclusion that this is one of our biggest flaws. |