Develop initial design

[mbland]

Here are some initial design ideas for the USDS Hub ("I want to..."):

• discover all US Digital Service teams, members, grouplets, and guides.
• decentralize updates and avoid Jekyll slowness by allowing other teams to manage their own individual Hubs and repositories.
  • 18F can provide hosting using different webhooks/Jekyll processes to build the team-specific Hubs.
• bind together team, project, grouplet, and possibly guide data from the different Hubs via their APIs to provide:
  • a high-level list of {team members, projects, grouplets};
  • navigation directly to a {team member, project, grouplet} page in the respective team-specific Hub; and
  • a unified search across teams.
  • The ./go script can compile these into a corpus. Or could a Jekyll plugin do the trick?
  • If client-side search isn't feasible, consider an Elasticsearch backend that consumes Hub API data (Jekyll pages API), or feeding it to the DigitalGov search engine.

Note that the USDS Hub isn't just an instance of 18F Hub; it's its own separate product with a different architecture that aims to link together separate 18F Hub instances. This is an alternate solution to scaling the 18F Hub itself across multiple teams/organizations. That said, many of the same design principles should apply, and some of the same software components may be reused.

cc: @meiqimichelle @afeld @gboone @elainekamlley @brethauer @shawnbot @OriHoffer @aaronsnow

[meiqimichelle]

@mbland Can you make separate issues for the software solutions versus the design mandates (and/or product outcomes)? It gets a bit confusing to follow when they are together :-/ I'd pull them out myself but I think you have the current 'lay of the land' in what 18F/USDS have been talking about!

[mbland]

@meiqimichelle: Done in #2. So here's the implementation-free list as I see it so far:

• discover all US Digital Service teams, members, grouplets, and guides by providing:
  • a high-level list of {team members, projects, grouplets};
  • navigation directly to a {team member, project, grouplet} page in the respective team-specific Hub; and
  • a unified search across teams.

Not much to it as I currently see it, really. :-)

[meiqimichelle]

Thank you @mbland :D Much clearer!

[meiqimichelle]

Chatted with @mbland on next steps. It seems to us:

• I will connect with Nick Bre. on "Lean LeanUX" implementation in this process
• I will organize a hour to two-hour brainstorming/design studio on how best things like hubs should look/work and try to involve more of the design team (and of course anyone else who is interested)

This is because we think that the USDS implementation of the Hub will actually be pretty similar to our 18F implementation, except that it will likely surface a difference level of information at first. The problem with all the Hubs seems to be one of search/browse and discovery initially, and then allowing for deeper dives as necessary. Additionally, this is the direction that the backend is heading to support these types of user stories.