Skip to content

Design

Jump to bottom
Neil Johnson edited this page Nov 10, 2021 · 2 revisions

The title bar

  • The title bar runs across the top of the page and includes the main menu burger on the left.

  • Keep it simple: Name of App + Election.Name

Common UI Elements

  • The title bar, and the area directly below it, may include breadcrumbs and other controls that appear on every page.

  • For the next version, add:

    • Forward & Back arrows (useful for navigating/scroll thru objects of the same class)
    • Publish: Commit changes to the server.
    • Validate: Error check for class of objects active (ex: If editing People, only check People objects), would also happen before any Save but also useful to have before committing changes. (Open Design question is allowing Saves while errors are present?)

The main (left) menu

  • Clicking on the menu burger button on the title bar summons this menu and greys out the active data entry component.
  • This is really the key to nail at this time. I may be biased by the NIST 1500 spec, but suggest using that as the foundational hierarchy. Where discussions IMHO get tricky is deciding how to enumerate objects below that (in some cases). IMHO, :

Top Menu

  • Election
    • New/Open/Close/Save/SaveAs/Delete
    • Headers (I noticed this got added to Ballot Studio. Brian (presumably) added as a top level object but IMHO it’s either an Election or BallotStyle attribute)
    • Candidates
    • Contests
      • Selections
    • Ballot Styles (IMHO an awkward name, maybe something like “Ballot Definitions”?)
  • Parties
  • People
  • Offices
  • Geo-political Units (kind of a mouthful, TBD if this should have another noun?)
    • There will commonly be a lot of these (often north of 100, and some case multiple hundreds)! I wouldn’t suggest attempting to populate the list in the left menu. Even enumerating GpUnit.Type(s) is cumbersome. I’d suggest both having:
      • A “Search” function either by GpUnit.Name or GpUnit.Type
      • Some form of “tree” control that would show all GPUnits hierarchically presented.
      • (This is a hard problem, other thoughts welcomed and encouraged)
  • Validate: Error check to flag major (logic flaw) and minor (unused objects in file) problems

Other design principles and questions

  • As a core design principle, I’d advocate keeping the main (required) fields in the primary UX/workflow, and delegating the optional fields in a separate “More…” UX. Example: Candidate contact info, slogan, etc. is not critical path, so should NOT occupy screen space on primary screen for Candidate info.

  • I realize as time goes on this may get complex and potentially need to be different for different customers.

  • All editable text should be rendered in an edit control: The 16-34-23 attachment doesn’t honor this.

  • What is the initial “File/New” workflow? Some type of (optional) wizard? IMHO, coaching (especially newbie) users thru completing Parties + People + Offices + GP Units before attempting to populate Elections will save a ton of user frustration…

  • Allowing for incomplete templates with Parties, Offices, and GPUnits? I can imagine common use cases where these don’t change so much from election to election (assumes a superset of all possible offices that would have unnecessary ones deleted each election), so local election officials (LEOs) start from a template and just populate People & Election data per election… Entering all GP Units each election will be a PITA and likely not to change beyond every ~10 years…

  • I see an opportunity for some time saving “short cuts”:

    • Auto populate all People from the People section to Election.Canidates
    • Auto populate all Offices from the Offices section to Election.Contests

  • Looking at this screen shot (and also in the 16-33–23 attachment) Raised questions for me if we’d actually expect to see multiple Election objects defined in the same EDM file? I realize it’s technically possible by spec, but I’m unclear if that is a real world use case? @John Sebes do you have thoughts/insights on that?

  • I’m conflicted on the proposed display of the common data across all Elections (type, start/end dates, scope) & Election.Contests (District, Votes allowed, etc). The UX shown on 16-34-10 and 16-33-52 where the shared data is shown on the left and list of sub-objects is shown on the right raises questions on which screen(s) would the common data (on the left) be editable? All? Or a separate screen to edit those? I’m inclined to want to separate them but that raises questions on how to label the shared data vs. multiple sub-objects…

Wireframes

Clone this wiki locally