discuss roadmap based on information architecture

[chadwhitacre]

Here's an IA that I did (click to rotate properly?):

[chadwhitacre]

Some things I see going on when I consider the above map:

• Since drawing this, we've added the dashboard as the first item under profile (Improve the authenticated homepage #2809). "Home" now refers to the unauthenticated homepage, and the authenticated homepage is the dashboard.
• CC/BA really want to be somewhere under Profile > Account. But how would this relate to a modal (revamp checkout flow #1167)?
• We should fold For into Explore as part of downgrading communities to tags (downgrade communities to tags #3127).
• Explore and Search should be integrated one with the other (integrate Explore and Search #3221).
• I see nice tables as a potential unifying element across the site: Explore, Search, Members, Receiving, Giving, History, Events, and Elsewhere Teams (unify tables/listings #3222).
• We should also pay some attention to our forms across the site (clean up forms #3267).

Additional TODOs:

• invert Profile and Account (clean up Profile/Account IA #3236)
• further rationalize our navigation (get nav out of sidebar #3258)

[Changaco]

Account probably shouldn't be under Profile. I'm talking about the UI, not necessarily the URLs. You should have access to your account settings from the top nav. The subnav of the Profile page shouldn't contain Dashboard, History, Widgets and Account (except maybe for admins).

[chadwhitacre]

@Changaco You would put History and Widgets under Account?

[Changaco]

You would put History and Widgets under Account?

In the UI yes, I would link to them from a dropdown in the top nav, and hide them from the Profile subnav (except for admins).

[chadwhitacre]

What's the relationship between Profile and Account? What do those mean?

@rummik has suggested before changing Account to Options or Settings.

[Changaco]

What's the relationship between Profile and Account? What do those mean?

Profile is the public subset of Account, it's what others see. Currently that's 2 or 3 pages: Profile, Receiving, and Members. #3112 will add Giving.

[chadwhitacre]

Profile is the public subset of Account

Okay, so Account would look like this?

Account
  Profile
    Basic Info
      Statement
      Funding Goal
      Teams
      Communities
      Social Profiles
      Other Receiving Options
    Giving
    Receiving
    Members
  History
  Widgets
    Button
    Badge
    Giving & Receiving Widgets
  Settings
    Username
    Account Type
    Available Money
    Adding Money
    Withdrawing Money
    Email Addresses (Private)
    API Credentials
    Privacy
    Notifications
    Close
  Events

[chadwhitacre]

Settings looks messy, maybe Basic Info, too.

[chadwhitacre]

Also, API Credentials isn't a setting that I can change. Maybe we should fold it together with Widgets? Also, "Embed" is more common than "Widget":

https://developers.facebook.com/docs/plugins/embedded-posts
https://dev.twitter.com/web/embedded-tweets
https://medium.com/@Medium/embed-medium-anywhere-3eaed64aed8a
http://blog.vine.co/post/55514921892/embed-vine-posts
http://embed.ly/

How about this as a target?

Account
  Profile
    Basics
      Statement
      Funding Goal
      Teams
      Tags
      Social Profiles
      Other Receiving Options
    Giving
    Receiving
    Members
  Embeds & API
    Button
    Badge
    Giving/Receiving
    API Credentials
  Settings
    Basics
      Username
      Account Type
      Available Money
    Funding Instruments
    Email
      Addresses
      Notifications
    Privacy
    Close Account
  Events

[Changaco]

The API key is a setting you can change, it is in fact a randomly generated account password, the web UI just doesn't have a form to log in with it.

[chadwhitacre]

You can regenerate it, is that what you mean by "change"? You can't set it to something arbitrary, like you can with a password.

[chadwhitacre]

Eventually I think we want multiple API keys.

[Changaco]

I don't think we want to switch to Embed, because the widgets don't actually embed any user-generated content like a tweet or a blog post.

[chadwhitacre]

I don't think we want to switch to Embed, because the widgets don't actually embed any user-generated content like a tweet or a blog post.

Okay, but they do embed HTML elements into another page.

[Changaco]

Eventually I think we want multiple API keys.

I think it's OAuth tokens you want.

[chadwhitacre]

Our "widgets" aren't really widgets:

In computing, a web widget is a software widget for the web. It's a small application with limited functionality that can be installed and executed within a web page by an end user. [...]

Widgets often take the form of on-screen devices such as clocks, event countdowns, auction-tickers, stock market tickers, flight arrival information, daily weather etc..

http://en.wikipedia.org/wiki/Web_widget

[chadwhitacre]

I think it's OAuth tokens you want.

Sure. I have in mind GitHub's model, which conflates the two.

[chadwhitacre]

I think we should evolve Events into a user-accessible Audit Log.

[chadwhitacre]

Let's move the Embed vs. Widget conversation to gratipay/inside.gratipay.com#125.

[Changaco]

Proposal (changes marked with asterisks):

Account
  Profile
    *Presentation*
      Statement
      Funding Goal
      Teams
      Tags
      Social Profiles
      Other Receiving Options
    Giving
    Receiving
    Members
  *Embeds/Widgets* (no API stuff)
    Button
    Badge
    Giving/Receiving
  *Balance & History*
  Settings
    Basics
      Username
      *Password* (replaces "API Credentials")
      Account Type
    Funding Instruments
    Email
    *Notifications* (doesn't go under Email because it also handles on-site notifs)
    Privacy
    Close Account

[chadwhitacre]

Inverting Profile and Account reticketed as #3236 and noted above, at #3220 (comment).

!m @Changaco

[chadwhitacre]

Presentation is awkward, imo. Profile > Basics would be parallel to Settings > Basics.

[chadwhitacre]

*Password* (replaces "API Credentials")

Interesting. Will I be able to have multiple passwords?

[Changaco]

Presentation is awkward, imo. Profile > Basics would be parallel to Settings > Basics.

To me "Profile Basics" looks awkward, and I don't see why we would want a parallel to Settings.

Interesting. Will I be able to have multiple passwords?

I don't see any use for that as long as we don't have permission scopes to attach to them.

[chadwhitacre]

The work on #3236 is leading into discussion about nav and layout, reticketing as #3258.

[chadwhitacre]

We're discussing the purpose of this ticket over at #3258 (comment).

My purpose on #3220 is to wrestle with our information architecture, and let that drive our product development decisions. As I say, there's a dialectic between our mental model of the product and our implementation of it. #3220 is one end of that, and the PRs we're making are the other end.

I want clarity about our product.

[chadwhitacre]

Deleting from #3258 and reposting here ...

@Changaco A couple times now you've made a distinction between UI and URLs (#3220 (comment), #3236 (comment)). I don't think that's a helpful distinction. We can't not have URLs, so we need to design them at some point. Furthermore, they're visible to users, and, like it or not, users do in fact use them. I think we should think of URLs as a subset of UI, that is, as one aspect of encoding our information architecture.

[chadwhitacre]

I've added this ticket to the top of http://inside.gratipay.com/big-picture/product. This ticket should result in a significant revision of that page.

[chadwhitacre]

I covered a desk with paper this afternoon, trying to wrap my head around what we need to do on this ticket. A couple teaser photos ... user goals front and center, flanked by other major concerns, with IA along the back.

[chadwhitacre]

See gratipay/inside.gratipay.com#163 for follow-on conversation. I expect to use the new Product page to talk about intent when introducing PRs into the pipeline.