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.
Details
- Reviewers
epriestley - Commits
- Restricted Diffusion Commit
rPe9f4ca6ca338: Redesign PonderQuestionView
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.
Diff Detail
- Repository
- rP Phabricator
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
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:
Quarter | Tokens | Notes |
---|---|---|
2014 Q1 | XXXXXXXXX | |
2014 Q2 | XXXXXXXXX | |
2014 Q3 | XXXXXXXXXXXXX | |
2014 Q4 | XXXXXXXXXXX | |
2015 Q1 | XXXXXXXXXXX | |
2015 Q2 | XXXXXXX | Tokens were put in "Actions" dropdown late in Q2, I think? |
2015 Q3 | XXX | |
2015 Q4 | XXXXXX | |
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:
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.
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.
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.
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.
Yeah, I'm not a fan of the pile of similar actions in Maniphest either. I think that's definitely something we can solve.