Page MenuHomePhabricator

Redesign PonderQuestionView
ClosedPublic

Authored by chad on Feb 20 2016, 9:43 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Dec 20, 12:20 PM
Unknown Object (File)
Thu, Dec 19, 4:56 PM
Unknown Object (File)
Sun, Dec 15, 5:59 PM
Unknown Object (File)
Thu, Dec 12, 7:13 AM
Unknown Object (File)
Tue, Dec 10, 5:32 PM
Unknown Object (File)
Sat, Dec 7, 4:07 PM
Unknown Object (File)
Fri, Dec 6, 4:11 AM
Unknown Object (File)
Tue, Dec 3, 1:29 AM
Subscribers

Details

Reviewers
epriestley
Commits
Restricted Diffusion Commit
rPe9f4ca6ca338: Redesign PonderQuestionView
Summary

Full new UI, testing some upcoming treatments for consideration in other View controllers. Small tweaks to allow PHUITwoColumnView to have fixed and fluid width, and let TransactionCommentView go fullWidth.

Test Plan

Tested a number of Ponder cases, New Question, with and without summary, with and without answers, with and without comments. Mobile, Tablet, and Desktop layouts. Verify Project and Profile UI's still in tact.

Screen Shot 2016-02-20 at 1.44.30 PM.png (2×2 px, 438 KB)

Screen Shot 2016-02-20 at 1.44.08 PM.png (2×2 px, 363 KB)

Screen Shot 2016-02-20 at 1.44.41 PM.png (2×2 px, 579 KB)

Diff Detail

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

chad retitled this revision from to Redesign PonderQuestionView.
chad updated this object.
chad edited the test plan for this revision. (Show Details)
chad added a reviewer: epriestley.
  • Remove voting PHP code

Sorry for the delay on this, I've been waiting for a morning when I'm well-rested and brimming with cheerful optimism to chew on it a bit -- I think my "useful/creative design/UI ideas/feedback" brain requires more sleep than my "mechanically move code around" brain. I am not particularly sunny this morning, but this has been sitting here for a bit.

This seems technically fine, with one caveat (see inline). I think you'll probably get a Column "voteCount" may not be null! error when creating a new answer. If you do (and even if you don't), easiest fix is to just leave the voteCount column intact and initialized to 0 for now until we actually remove it in some future diff (like D15216 removed some very old Maniphest columns).

The UI changes seem fine for Ponder, but I'm not sure how they would look in other applications like Maniphest. Two general concerns I have:

First, just physically, it seems like there's no way the properties could fit into a column on a task, revision, or commit, since these objects have tons of properties. Maybe I'm just not being imaginative enough, but it's hard for me to conceptualize what this UI would look like when applied to those objects. Is the right column just a mile long?

Second, I have pretty mixed feelings about burying actions inside "Actions" dropdowns. It's definitely more appealing visually and helps the UI feel sleek and uncluttered, but, at least for me, it's also a pretty big material step backward in utility.

The worst of these for me is tables of contents in Phriction (I think a user opened a task somewhere) -- I somewhat-frequently try to link users to a particular section of the documentation, and the TOC being buried in a menu just feels laborious every time. This isn't the end of the world or anything, but it feels like we're putting too much weight on sleekness every time I hit it.

Perhaps another example is T9208, where a user couldn't even figure out how to vote (the option is buried in a menu). I mention this partly because I had the same difficulty earlier when reviewing Ponder to give you some feedback prior to this change!

Here's some data on total number of tokens given in Phriction:

QuarterTokensNotes
2014 Q1XXXXXXXXX
2014 Q2XXXXXXXXX
2014 Q3XXXXXXXXXXXXX
2014 Q4XXXXXXXXXXX
2015 Q1XXXXXXXXXXX
2015 Q2XXXXXXXTokens were put in "Actions" dropdown late in Q2, I think?
2015 Q3XXX
2015 Q4XXXXXX

Obviously, that data set is small and it's hard to draw any conclusions from it, but it seems like hiding "Award Token" inside a menu may have tanked the action rate, which isn't a big surprise. And maybe that's fine, since we aren't building Token-Awarding software, but if Tokens isn't valuable enough for us to add a top-level action to, say, double its usage, should it be in the product at all?

I sometimes see feedback from users that GitHub is "intuitive" and "easy to use" and other language suggesting that they perceive it as sleek and well-designed, while Phabricator is "terrible", "the worst thing ever", "wholly unintelligible", "literally satan", etc., but I think this is just familiarity or other user-ness, not a criticism with any real substance, since GitHub is covered with buttons and not actually sleek:

Screen Shot 2016-02-23 at 5.48.04 AM.png (247×999 px, 58 KB)

Overall, I'd like to try to find a way forward that doesn't require us to put actions inside a dropdown. Maybe one idea is to make a hybrid of this design and the current actions menu, and separate it:

+----------------------------------------+  +=============+
| Content Column                         |  | Actions     |
|  Reviewers: alincoln                   |  | X Edit      |
+----------------------------------------|  | Y Token     |
|                                        |  | Z Subscribe |
|                                        |  +-------------+
|                                        |  | Subscribers |
+----------------------------------------+  | a, b        |
  |                                         | Tokens      |
  timeline                                  | q, r        |
  |                                         +-------------+
  .
  .
  .

In this approach, we'd keep actions on the page in roughly the same format they currently exist, but move common, not-too-useful "secondary" properties (tokens, subscribers) under them, while keeping "primary" properties (reviewers, change properties, task details) in the main view.

We'd reduce the width of the content column, and could consider moving from there to fixed-width (or optional fixed width) in the future.

So basically exactly the same as this except no dropdown, I guess?

src/applications/ponder/storage/PonderAnswer.php
21

Removing this without deleting the column might create an issue with creating new answers?

Even if it doesn't, it's probably better to leave it in place for now until we actually remove it in a future storage patch, just so the PHP definition of which columns exist stays in sync with the MySQL definition of which columns exist.

This is more of an interim step, I didn't want to do too much in one diff. My rough plan here is:

  • Try actions in the sidebar, like you mention. This was difficult to do given how the CSS/Mobile layouts work. I think it's not going to be a simple diff to get them moved over.
  • Sidebar for some properties (like subscribers, projects, milestones) offer new UI possibilities. I'll put together a Photoshop mock sometime soon to explain, but I think we can make these richer/interactive.
  • Some properties might be better in the header (like author or priority).
  • I don't really imagine Differential in this UI, at least not without a lot of study. Differential has too many unique things going on. If we do redesign it, it should still likely be very unique given the vast amounts of information it needs to present.
chad edited edge metadata.
  • Add back '0', test new question creation

Hard to really see clearly, but my current thought is that we'll have a few different page layout choices.

  • Object/Property/Action, more of our "basic" layout, good for simple items like Herald, Almanac, etc
  • DocumentView, good for long form content (Phriction, Phame, Legalpad)
  • DiscussionView?, good for pages that likely are centered around discussions (Maniphest, Ponder, Countdown, Discussions?, etc)
  • Custom? (Differential, Pholio, etc)

I definitely don't want to build custom UI for every app, so I think with a little iteration on Ponder, we can cover a number of use cases on object pages that are heavier on discussions.

epriestley edited edge metadata.

This was difficult to do given how the CSS/Mobile layouts work. I think it's not going to be a simple diff to get them moved over.

We can also possibly look at using JS to help with this if we can't get it working with a pure responsive layout. I'm not thrilled about this since it's going to be a little fragile, but as long as it's just a few major layout elements and not every single thing on every page I think we're probably OK.

This revision is now accepted and ready to land.Feb 23 2016, 11:48 PM

There are "incomplete but you get the idea" mocks about Maniphest in Dropbox. I think for actions, I'm overall OK having them, but I want them to be more important? I think there are 9 on Maniphest and that doesn't include attaching Commits or Phrequent. Maybe putting our heads together over a coffee could yield some ideas.

This revision was automatically updated to reflect the committed changes.

Yeah, I'm not a fan of the pile of similar actions in Maniphest either. I think that's definitely something we can solve.

Yeah the GitHub UI makes tons of sense.

pasted_file (81×232 px, 7 KB)