Design of the Profile Display

[CodedOre]

As I have merged in the Profile class (containing extended data for a user) today, I think it's time to discuss how they should be displayed in the user detail page. In fact, I think we did not discussed the design for the user overview yet...

I have created a prototype today, but would like to get some feedback before implementing it.

[IBBoard]

Looks good to me. All the bits I'd expect on the profile data - avatar, background, name, handle, bio, joined date, location, website.

I thought it might be nice to put the follow button in the white space on the wider one, but a) that involves it jumping around in weird ways between wide and narrow views and b) I'm sure there will be places where it is in wide mode but the user's display name is long enough that there's not much white space to use!

I think we'd need a different icon for "joined" though. That's the RSS feed icon. Or Windows wifi, but flipped horizontally. Not sure what we'd use, though. Calendar?

I was going to comment on the lack of "Favourited" list, but it looks like we don't have that in Cawbird anyway 🙂 I think we can do Twitter's "Tweets" and "Tweets and Replies" with a toggle in the Posts view. I wouldn't bother with Twitter's "Media" (partly because there's not a single API for it and I think we'd have to rely on Search with its 7 day history, and partly because it's a low priority feature). Followers, Following and Lists are probably still the most useful.

[CodedOre]

Alright, got some feedback from the Gnome Design team.

One of the first points was the switcher for posts, follower, etc.
While Adwaita might get a dedicated design for inline view switcher which we could use, it was brought up that the categories Followers, Follows and Lists "aren't equal nor homogeneous", so it could make sense to place the access to those elsewhere.

Another point was to make the metadata more subtle and drop the list.
While I personally don't think it looks bad, it does consume a lot of space, so it probably makes sense to replace it with something more lightweight.

With both of these done, the prototype would look like this:

[CodedOre]

Got even more different:

[IBBoard]

They've got a point (which is why they're a design team!).

I think a mix of those two might be best - I prefer the name next to the avatar on wider displays because there's going to be a lot of empty space in that second design. But I can see why they don't want to put a button over the cover picture.

The details including follower count make more sense below the bio rather than above the bio, because it keeps "stuff the user wrote" (name and bio) and "bulleted stuff about the user" (followers, joined date, location, URL) together in their own groups.

Would timeline and lists make more sense as different views now? Lists aren't entirely equivalent to a timeline, but the list does contain a timeline, so it's only one step away and I can't see a better place to put it. The ⋮ button wouldn't be a place that I'd look for lists, because it's for profile-related actions (block, mute, etc). A third view could then be likes (although I suspect the Twitter v2 API might burn a lot of tweet credits on that!)

Also, I think split buttons are out of favour in design at the moment and separate "more" buttons are better where possible. It probably makes sense for accessibility.

[jannuary]

Some personal design exploration:

[IBBoard]

Interesting. I'm not keen on "header bar disappears" - it's fine for mobile but desktop doesn't have the same edge of the device and so it'll look odd and out of place. The "pills" could be a good way to do the filtering of "don't show RTs" etc, but "Likes" is a separate feed and needs a separate list. We could theoretically fetch both feeds and merge the lists BUT a) it'll make the UI unclear, b) likes are not RTs and shouldn't be treated like them! (that's part of the reason we're using Cawbird and not Twitter Web!) and c) it's an extra request that counts towards the tweet cap in the v2 API, so we should avoid making that call if people don't want to see it.

[jannuary]

I mean, it's not a matter of the header bar "disappearing" - the header image is basically kind of an oversized headerbar in of itself, and would just collapse to a regular headerbar when scrolling.

About likes, yeah I suppose that's true, but otherwise I'm not sure how would showing likes be exposed in UI, if at all.

[IBBoard]

I guess "disappearing" is the wrong word. There's no system-themed header bar, which this kind of app still needs on desktop.

I think the likes are going to have to be a separate list in a stack - one for the timeline tweets, one for liked tweets, and one for lists (which then becomes a list of tweets when you pick a list). It's not 100% "equal and homogenous" but it's close.

[CodedOre]

I now have (mostly) implemented the UI for the profile information:

One thing is missing currently, which is the profile header, which opens a question:
Until now, I have just assumed that we keep the image placeholder at a static height of 200px. While this makes the rest of the UI easier to manage, it would result in the picture being cropped to some degree, as the aspect ration changes the more width an window has, while the one of the image (15:5) stays the same.

Question now is: Do we accept the cropping and allow to click on the profile to open an MediaDisplay with the profile header? Or do we want to keep the header completely visible no matter what?

[CodedOre]

If you ask me the light header bar (with only back and window control buttons) contrasted with an image directly beneath is not necessary a best design.

Here is the discussion with the design team about this:

Also the links that was posted by Exalm: https://twitter.com/gilbouhnick/status/1094717120909398016?s=21 https://www.b4x.com/android/forum/attachments/28-05-_2016_19-11-57-jpg.44477/

[IBBoard]

“A Scrim is a semi-transparent gradient layer that helps Text appear more readable against backgrounds.”

Or just keep the header bar and don't worry about putting text over an image 😁

Like I said before, I think that headerbar-less version might work fine on a phone (where you often don't have a header bar anyway, because there's no close button etc). But on a desktop it's just out of place. I'm sure it's pretty a lot of the time, and cool that we can do it, but "consistent and usable" >>>> "pretty".

[CodedOre]

You have a point there too.

So, I'm going to implement an classic header bar to the display. However, I might keep the code for the inline header.

I already thought about adding an hidden setting (only available through dconf) so you could move the MediaDisplay into the main window, as this would be better on phones and as I find it a massive pain to resize an modal window.
So, I might do this with the header as well, using a normal header bar as default with an hidden option for the likes of me and the phone distribution maintainers.

[jannuary]

I now have (mostly) implemented the UI for the profile information:

Are we not doing AdwAvatar here? :/

[CodedOre]

Our UserAvatar uses AdwAvatar in the background, with an additional css class to make it the rounding optional.

See IBBoard/cawbird#199