-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Information design and UX improvement - omnibus exploration thread #808
Comments
Impressions@tlongers I went through and took notes about my UI/UX impressions. Overall I think the site looks good and the simple interface does a good job of helping digest complex relationships. I noted some spots that could be tightened, and also asked a few questions about potential features and improvements. Thanks for sharing all of that relevant information, that was very helpful to understand the background. Please forgive me if y'all have already discussed some of these points in the past — I'm not trying to rehash old discussions or point out obvious things that y'all have more insight about from your user research. cc @hancush and @tonysecurityforcemonitor Site navigation and overall helpTerminologyOne thing that's missing is some sort of glossary for the terms (like units etc). One can make assumptions about what the various distinctions means, but this seems like something that one would be better off not assuming about. I know this information is in the docs but the docs aren't obviously accessible — something as simple as a link to the docs in the navigation menu would help. The question mark icons attached to various terminology link to the appropriate place in the docs, but it could help to have a single place where you can access everything while also linking in bits and pieces. (It looks like Hannah's wireframe in #807 helps address this issue.) Also, in the footer, the link Grokking the data / understanding how to use itThe Myanmar analysis is helpful context for navigating the site because it shows how the data is used to research them. A guide on the site like that could be a useful quick/dirty “guide” for using the site. Detail pagesLacks a header for the type of pageEach page needs a larger bearing/signal about what type of entity it is. For example, on this page, the only indication that it's a "unit" is the icon, otherwise it's not always obvious this is a unit. I came to this page from the search and that page includes a header. Kowing that I was searching units somewhat clued me in on what I was looking at, but a distinct way to label the type of detail page could strengthen the bearing. It's especially confusing because the unit and personnel detail pages have similar content that is styled and formatted the same way. Country detail pageWould it be useful to have a country detail page where you can see all personnel, all units, and all incidents for a country on one page? I know that the search can sort of act like that via what filters are selected, but it’s not obvious that you can search via country. I discovered that I can do a sort of hacky, generic country search from the home page by not inputting any text in the search field — not sure if that's an intentional feature but it's a useful workaround nonetheless. A question that might inform a decision to create a feature like this: when somebody uses the data for research, are they generally looking at a specific country? GraphsI'm curious what sort of user feedback y’all have gotten on the current graph implementation? I like the hybrid approach of showing the parent units in a graph and then listing the subsidiaries in a table (One of your docs mentioned that people understand tables, so this makes sense). Does this graph design give the users what they need? I'm wondering if it would be worthwhile to implement a full graph view like the original version, in addition to the hybrid graph + table interface? SearchDate FiltersAt the top of the filters, you can filter by date. What the date filters is not obvious since the filters also have a cited date section (again, I can make assumptions but I can't fully trust them). Also, it would make sense to group all the date-type filters near each other, rather than having a date filter at the top of the filters and the cited date filters at the bottom of that section. Mobile friendlyWhen searching on mobile, you have to scroll through all the filters until you get to the table of search results. That's not ideal since it essentially puts the search results below the fold. Maps
These might be things y'all have considered and opted to not implement based on the user feedback, especially the part where y'all learned that the maps weren't as useful as the graph view. But I just wanted to share my impressions. |
Thanks @smcalilly HomepagePlenty of practical stuff to do here:
Search viewsAgain, some easy wins I think:
Record viewsGood observations, thanks Sam. So, practically we have these items:
We also plan to introduce a new datatype into records ("training and assistance"), which will need a bit of careful work to do properly. VisualsI'm cautious about the value of graph/map visuals vs the difficulty of implementation in a satisfactory way. So far, we've adopted a "show one attribute in one record" approach with the visuals in WWIC: show sites, show areas of operation, show the upwards command chain. The maps are deliberately dumb (no filters, etc) too, as we adopted the idea that when we show visual, there should be no need to do more to the data. The ony place we step away from that is the forward/backwards time switch in the command charts. The issue with our geo is the combination of point and polygon data, the geospatial data available to us, and the rules that we encode locations with only the degree of precision that our underlying source can evidence. Largely, this means that we may have items on a map that appear precise but are not: in this case, maps accentuate certainty in a misleading way. Any map needs pretty careful design, along with ways that the visual display is balanced out with in-situ explanatory material or mechanism that help the user navigate ambiguity. This adds an extra level of difficulty I think. Graphs become very big very quickly, presenting huge UX challenges. This is why we only show the upwards command chart, because it only gets simpler! In general, the comamnd charts are well received and numerous researchers get a-ha moments from seeing the raw data come alive in them. As with maps, we've implemented graphs very simply at the record level. The challenge is whether there is anything better a visual on a specific record, and a wholesale way of exploring the data. I'd feel more confident on both if we'd found a way interally to resolve the challenges easily, but we still struggle with them. For now, I'd say leave the visuals be, until we have thoroughly cracked the graph/map visuals in our internal practice. |
WWIC is nearly five years old! @smcalilly Could you take a look across the platform (with fresh eyes) and consider the following:
Here are some background materials you might find useful:
Also, here are some related products I've seen recently that might contain some inspiration:
The text was updated successfully, but these errors were encountered: