Show HN: New data portal for Medicare/Medicaid I designed(data.cms.gov)
data.cms.gov
Show HN: New data portal for Medicare/Medicaid I designed
http://data.cms.gov/beta/
8 comments
At a glance, I'd be unclear on what set of scenarios they expect the site to help out with. The person would need to type the right search term and hopefully land on the right result. If they wanted to use the navigation, it seems hovering over the menu items doesn't show you the structure of the site-- you need to click into each individual tab. It's pretty but hard to gauge how useful it is.
Totally! I think the search term issue will get addressed as the datasets get tagged with more near and similar terms so it populates the search results with a wider net of results. (like misspellings, synonyms, topic and category terms, etc).
I feel like we talked about topics being a search result too, but there was some barrier to the search tool to get it to work with other page types. That'd fix a lot too.
I feel like we talked about topics being a search result too, but there was some barrier to the search tool to get it to work with other page types. That'd fix a lot too.
Honestly, love the design, few location that will need accessibility and bug on overlays and a few margins, browser stack or something similar in testing by your QA engineer all full cylinders.
hi! lemme know what you think!
Wow, so cool that you did this and
are looking for feedback on HN!
I have worked on some projects inside big organizations with a lot of red tape and politics and I have to imagine that this must be a real challenge for you as well right? What have you found worked in terms of being able to put users first instead of higher ups in the chain of command?
Search:
- I tried 3 search queries and no results.
- It looks like the entire corpus is only 97 entries. I would suggest considering removing search all together, and instead just putting the data in a single packed table. You can fit 100 rows of data in 3 scrolls. Then someone can "search with their eyes" or even ctrl+f.
- As a rule of thumb, I try to wait until I have over 10,000 rows before I add any type of search to a page. At the very least, I never add search when I have less than 1,000 items. Measure the time it takes people to find things and you'll see probably a 10x speed up if you go to a single page.
Information Density:
A general critique I have is that there is very low information density on this site.
You could fit 1,000% more information on these pages.
A book I highly, highly recommend, that you can buy used for only $1.49, is New York Times Page One:
https://www.amazon.com/New-York-Times-Page-One/dp/1578660882
NYTimes has been serving the people of America for over a century, and so you'll see the patterns they've evolved over the past 100+ years. One of the main ones is high information density. I would try and cram more and more on the page. People that need bigger fonts and more accessibility have a range of tools on their devices to transform sites into accessible version for them. Now I've been in places where leaders pushed back against this, but I can tell you for a fact that your numbers will skyrocket if you go to higher information density which will increase the odds people will find the info they are looking for in a shorter time period and eventually come back to your site.
Visualizations:
I would put search in a corner, and one of your most interesting visualizations front and center! What are the top 10 coolest stories you've found while working on this site, with this data? Bring some of those to life!
Great stuff! Thanks for your work and for sharing here!
(Source: I work on software at Our World in Data, and am also a medical researcher and work on various related tech)
I have worked on some projects inside big organizations with a lot of red tape and politics and I have to imagine that this must be a real challenge for you as well right? What have you found worked in terms of being able to put users first instead of higher ups in the chain of command?
Search:
- I tried 3 search queries and no results.
- It looks like the entire corpus is only 97 entries. I would suggest considering removing search all together, and instead just putting the data in a single packed table. You can fit 100 rows of data in 3 scrolls. Then someone can "search with their eyes" or even ctrl+f.
- As a rule of thumb, I try to wait until I have over 10,000 rows before I add any type of search to a page. At the very least, I never add search when I have less than 1,000 items. Measure the time it takes people to find things and you'll see probably a 10x speed up if you go to a single page.
Information Density:
A general critique I have is that there is very low information density on this site.
You could fit 1,000% more information on these pages.
A book I highly, highly recommend, that you can buy used for only $1.49, is New York Times Page One:
https://www.amazon.com/New-York-Times-Page-One/dp/1578660882
NYTimes has been serving the people of America for over a century, and so you'll see the patterns they've evolved over the past 100+ years. One of the main ones is high information density. I would try and cram more and more on the page. People that need bigger fonts and more accessibility have a range of tools on their devices to transform sites into accessible version for them. Now I've been in places where leaders pushed back against this, but I can tell you for a fact that your numbers will skyrocket if you go to higher information density which will increase the odds people will find the info they are looking for in a shorter time period and eventually come back to your site.
Visualizations:
I would put search in a corner, and one of your most interesting visualizations front and center! What are the top 10 coolest stories you've found while working on this site, with this data? Bring some of those to life!
Great stuff! Thanks for your work and for sharing here!
(Source: I work on software at Our World in Data, and am also a medical researcher and work on various related tech)
Hi! totally understandable with search. I think we went with search because, for the user base, they usually have a specific topic or database in mind. For people who don't know to search for, we have the category sections below Absolutely we need a better null-search state! (I'd do nearest-match and topic pages, but one release at a time. And CRAZY to only do search at 10k items! i mean, i do love opinionated design... but don't you find it hard to browse so many items?
Density - i am often against highly dense pages cus, for me, scan-ability and legibility are the most important. Big text and just a couple items for page seem to fit the bill. But i usually go denser on search-result-pages or dataset pages since it's more of a comparison step.
I wish we had more visualizations and stories to put front and center. Believe me, they quickly become super contentious! But that is the vision...
Density - i am often against highly dense pages cus, for me, scan-ability and legibility are the most important. Big text and just a couple items for page seem to fit the bill. But i usually go denser on search-result-pages or dataset pages since it's more of a comparison step.
I wish we had more visualizations and stories to put front and center. Believe me, they quickly become super contentious! But that is the vision...
What types of feedback did you get through end users so far regarding their expectations for information density?
It was mostly, when looking at search results, "is this the right dataset for me?" Particularly when many datasets have similar names or the title of the dataset was unclear. So we added descriptions and "quick-peaks/expand" in search results.
This is in contrast to the original version which was very dense tabular view, having people scroll sideways to parse or click into many pages what a dataset was about.
This is in contrast to the original version which was very dense tabular view, having people scroll sideways to parse or click into many pages what a dataset was about.