wiki:uiDesign

Current UI Design Notes

This page contains the design notes related to the User Interface. See the Backend Design and Design Goals for current development notes. The Schedule? has the best guestamates and rough work breakdowns for projected development timelines and where v3 is currently headed.

See: Dilbert "The Technology Demo"

  • One thought was to try and limit to single nav menu - no context menu or combined site nav and context nav when needed. This lessens confusion and aids simpler page design in light of required headers. However, the site nav and context nav are what users are used to and do add a pattern that can help with a user being able to understand the site and how it is organized as well as capabilities.
  • Putting navigation in a single NAV HTML 5 element enhances usability on small/mobile devices. Many pages really don't have complex context menu needs.
  • Recommended downward expandable left navigation rather than the traditional popout/popup. This again is better for small mobile devices. Current 2.3 solution is to have it popout. This is easily changed to slide in but the popout allows more page content to be seen.
  • Clearer, more meaningful navigation selections that a user can more readily understand. Top nav can should have 5 selections, left should have 5-7. Top nav possible items:
    • About
    • Important Health Topics
    • Community Comparisons
    • Health Indicators
    • Publications
    • Resources
    • Explore Health Datasets
  • Left nav should be more concise and less confusing. For example the left About menu could be limited to a much smaller subset of the main top About menu:
    • Welcome
    • Content and Usage
    • Help
    • Contact Us
  1. Site navigation could have main areas of user interest: Health Topics, Health Reports (or whatever makes sense to call them), Community Comparisons (or whatever makes more sense), Data Lookup (queries), About/Resources? (many sites have an "about" section), and Help (which could be put under the about/resources?).
  2. Each of the main nav items will need a good landing page that is similar to the main page. Slider that provides they key info and links. Followed by some basic text and indentured/expandable lists for navigation.
  3. It really makes sense to include the My IBIS and Search feature as part of the site header or main navigation. Might want to add the social networking links to the My IBIS or as part of the footer etc.
  4. For pages that need a context menu (IP, CP, queries, PHOM/set reports) we can put this as part of the page's body content where appropriate. For example maybe we make the IP report more like a set of pages of a report and have forward/backward buttons on the top of that content or a quick jump to drop down list etc. For the query system maybe we put the return to query builder and reset to default in the query selections area. The XML output could be put in the content footer area etc.

IF SIMPLIFYING:

  • Each main area would have a really nice welcome/homem type page with a slider that contains 4-5 sections with each section having its own related graphic and 3-5 highly used/most useful links.
  • This section of the site provides important information about our health and environment which we live.
  • We need the user to understand what this site is about - what we're about - not simply listing a set of features. We need to paint the picture so they can catch the vision - what is in it for me - what is offered.
  • Here's some important health topics that effect our community and why you should be interested. Learn more about the obseity epedemic. Pre teen births. Low brith weight. Cancer. See the complete list.
  • See how we're doing with specific health issues like drinking and water pollution. See the complete list.
  • See how various groups compare against each other on important health topics.
  • Create custom reports where you have the ability to set year ranges, pull data by age groups. See data by sex or geography or income level.

Issue with standardizing on hamburger slide out menus for desktop users or tablet users is that they see the options better using a mega menu and not having to go down the slide out menu levels (which does work and the right approach for small handheld devices).

HANDHELD NAVIGATION NOTES:

  • Mouse overs do not work.
  • Most devices browsers will jump to the <A> element instead of the label that is associated with the input element.
  • Fixed positioning is an issue if the metadata tag auto width is set.

UI

  • Starting with version 2.3, the core code will default to using auto adjusting CSS page layouts. This will allow the UI to more readily adapt to the various displays from small hand held devices, to tables, to large desktop monitors.
  • Rework the main section pages need to be clean, engaging menu type pages. Users scan and click - they don't read. Each main landing page (home, query, IP, pubs, about, help/resources) need to be a clean (lots of whitespace, not much text, and graphics), concise menuing page that clearly communicates what this section of the app provides. The current textual information should not be thrown away but can be contained below or on separate pages.

Admin App / Data Entry

  • Replace the admin app and database with an interactive edit in place view app.
  • This will help editors know exactly where the data is used.
  • The app will constantly provide a "preview".
  • The current thought is to use the view app's XSLT. The admin's app would include script that would attach/register the editing code. This editing code would know how to make the save request, validation rules, data type etc. The scripts would be attached via the ss.xslt mechanism.
    • XSLT would need to add ID attributes, new attributes like xpath to that data etc so that a request could be made to save and that the controller knows where to save it.
    • Types of values include:
      • wiki text - could have editor with the wiki options shown at the top of the editor along with real time display once submitted.
      • numeric
      • HTML_CONTENT - so could edit those types of pages as well.
      • SELECTIONS/SELECTION structs.
      • Dates
      • Drop down lists
  • SS CSS could be used to provide a visual clue that this is the admin app and not the production app.
  • Publishing would go through the repository so all files are versioned and deployed in the same way. This also allows local development to easily checkout or export the data files to work with. It can also allow for an editor to work offline.
  • The challenge is do we want/need selective content deployments. We currently handle this but it will get more tricky to do content management in light of adding IP type data to the repo and needing to publish only that IP. Could build a deployment type tool into the production view app or simply rely on batch scripts on the test and production servers. A deployment tool would consist of an interface that shows all the latest changed files since the last deployment along with a checkbox that the deployer can select/deselect. Pressing the button then loops through the repository files and does the update.

Charts and Maps

  • Maps are client side script based (Kendo widgets and Leaflet maps).
  • Map layers will need to be somewhat generalized so that it doesn't take a long time to download and process, and to avoid overloading the browser.
  • Maps and charts will be printable within the page but might be difficult to copy and paste into other apps.
  • Charting will be consistent with maps - client script based. We can still use the agileblox solution for current pages but there are tech SVG issues and licensing issues so it is recommended to scrap this code.
  • The map and chart code are independent from each other and should be adopter plugable (this is implemented starting in version 2.3).
  • Client side maps and charting will rely on data provided within the page. This will help with page security as well. Not planning on doing any type RESTful or webservice to provide data. This could be implemented in the future if needed.
  • Likely to use some advanced script based UI widgets for tables and to integrate with maps and charts. These table widgets provide much of the capability that exists within MS-Excel (sans the formulas). Some even have direct Excel import and export capabilities. The XSLT code will still produce a standard HTML table. Then if script is enabled and supported the standard HTML table will be hidden and the enhanced table shown. Might provide a control mechanism for this in case mobile devices have difficulty with the enhanced tables.

Reports and My Health Data

  • Will provide an interface to build and save custom reports. These reports are NOT XSLT views but are a series of page requests.
  • Set report definition will be able to use HTML_CONTENT urls, comparisons, or IP reports etc.
  • This mechanism will allow a User to build and share a PHOM, IP set report, or CP type report. It will also enable the system editors to use the same mechanism to define their reports - just like UT EPHT does with their topic saved queries.
Last modified 4 years ago Last modified on 12/16/15 16:10:22