Mockup for cawbird with libhandy

[CodedOre]

THIS COMMENT WAS MODIFIED

Changelog: - 04.08.2020: Initial Comment - 08.08.2020: - Removed Search as this idea was dropped. - Remove small-sized text in Content. - Added list modifier in Lists overview. - Added new Tweets section. - 13.08.2020: - Make content more simpler for implementation - 25.08.2020: - Modify content display for big window in Home Screen, added image placeholder. - 17.10.2020 First Change: - Changed picture placeholder trough actual image. - Used image is WebBanner from Gnome's Design Team app illustrations - Added media widget mockup - 17.10.2020 Second Change: - Removed "New Tweet as subpage" - Added image option to reply-mockup - 23.10.2020: - Modify MediaWidget Description

So, after already discussing it in an different issue, i now revamped my mockups for an "Cawbird 2.0", staying closer to GNOME's HIG and using the new Libhandy-Library.

Main Window

Like mentioned previously in another issue, the main window would have a few changes:

The buttons in the headerbar are reordered with "back" now the first element on the left followed by "new tweet". On the right side I would place an search button (more about that later) and an application menu, which would also includes the account switcher and menu. One thing to discuss would be if the application menu uses the official icon or if it would be replaced with the account picture, like with the current account menu.

The view switcher could be reimplemented with an adaptive HdyViewSwitcher.

The available Views could be narrowed down to "Home", "Lists" (which would also include favorites), "Mentions" and "Direct Messages", the last could need to be shortened to "DM's" on smaller windows.

Lists View

Since the lists view contains multiple similar lists, this would be a good opportunity to use an HdyLeaflet. This would result in the following result:

When the window is wide enough, an overview of all views are presented as an sidebar and a selected list will displayed left of it. Is the window instead too small, the user would first be presented the overview, and pressing an list name would reveal the list, and return would be possible over an gesture or the back button. The overview also contains an option button for each list for deletion and edit of an list.

The edit options could also be revamped by moving the delete button solely to this view and also adding an editable list of members, offering an delete button for existing members and an add button for new members.

Search

In order to make space in the view switcher, i would place the search button in the headerbar, where it also mostly reside in most GTK-Apps.

However, the search itself stays an independent view, so clicking the button will give you a blank view with the search entry, which is then populated with the search result.

When selecting the search button, we probably want to keep the previous view so when the search is closed again it would go back to the previous view.

Content

I would also redesign how content is displayed. For once, i would use GtkLists with a little space to the window border for an better aesthetic.

The right site of above image shows also how i would remake the detail view of an tweet:

• The tweet selected in an higher view will be highlighted with an bigger text font and an row highlighted with the system accent color.
• Threads replying to the tweet are shown in their own Lists, which has a small indent to the list with the selected tweet. Each thread get their own list, therefore giving a clear distinction between the threads.
• Selecting an different tweet opens a new detail view for the selected tweet.
• If their are tweets multiple levels above or below the current selected tweet, we should indicate this with an arrow an a "x more tweets" text.

I would use for these detail views an HdyDeck, which only shows one view at a time, but would allow an implementation of the back gestures of HdyLeaflet (as far as i know).

Media

In order to avoid pictures to be larger than the screen area, but also to follow better today's UI conventions, i suggest to make the media display a resizeable window with actual window controls. If the user did not resize the media window, it will use the size of MainWindow, otherwise it stores it own size in the settings. Thanks to HdyWindow, we are able to decide fully how content is displayed, so we can allow the media to be the only visible content in the window, showing controls only when you hover over the widget or on mobile tap on it.

The new media display should also include controls, like the still available window buttons, next and previous buttons, and additionally, a playback control for videos and view control buttons to make the media larger (as a default size, media should use their original size, unless this is bigger than the window).

Tweets

I would distinguish between two modes when tweeting.

If you create a new tweet, the user should be presented an clean "Create Tweet"- View with only the new tweet on an dialog. We display an "show emoji"-button only on desktop, as mobile users can insert emojis over the on-screen keyboard.

Images are handled like now and put into an row below the text-input after inclusion. If you have an image in the clipboard and press Insert we could append the new image to this row as well.

If you reply to an tweet, i would not open a new view/dialog, but rather display the edit screen inside the Content view so the user have the context.

---

So far for now. This are some parts how i would think we could improve how Cawbird is designed.

Feedback is welcome.

[CodedOre]

I have no idea what you mean by "extend" here. If you mean subclass, it's impossible, because:

1. HdyViewSwitcherButton is private
2. None of those classes are derivable

Right... So upstream would be the only viable option here. Would still leave the question on how beneficial such a feature would be outside of cawbird. Looking on my current desktop, the only app which would benefit would be Gnome Software (or what will be the successor of it in the long run)...

It might be a long-term benefit to upstream it, but I can't see Cawbird moving to GTK4 any time soon. We're already going to be cutting off some older Ubuntu users (IIRC) because of the minimum version of libhandy that we want to use. GTK4 currently seems to cut off ALL Ubuntu and Debian users and lots of other distros.

Because of this topic of "cutting of users" I wanted to work also on splitting the backend off the frontend.

You may have seen my latest prototype for an account switcher:

While this is better usable on mobile and desktop than the current app-menu approach, this will require libhandy 1.1 (as the required HdyFlap is still not in a stable release), so we could only provide packages for an HdyFlap-Cawbird with distros packaging it (I guess with Gnome 40 or so).

So, my thought was with splitting the backend from frontend, we would not need to weight a new feature over lost packaging support, since we could better maintain older version for those needing them for older distros or the poor people using Solus.

[alice-mkh]

That feature might be quite useful to be upstream really. But needs design, and if it's added, it will indeed be GTK4-only at this point.

The switcher looks good! Yet another reason to release 1.1 sooner than 40.

[CodedOre]

That feature might be quite useful to be upstream really. But needs design, and if it's added, it will indeed be GTK4-only at this point.

Well, than I could do later a feature request for that.

Question would be: Since this would affect GTK and libadwaita (as libhandy is called in the future), where would I ideally post the request?

[alice-mkh]

It needs changes in both, so GTK first.

[IBBoard]

Presumably, since all of this is based on GtkStack then we're still stuck with all the performance problems in #204?

[alice-mkh]

I don't see what that could have to do with stack tbh, unless you stuff tons of pages into it OR changes sizing everywhere between active<->backdrop which is a can of worms already.

[IBBoard]

I don't want to get too side tracked on this topic (it's more relevant to #204), but in summary:

• Ebassi said that CSS invalidation causes these problems, so it's just part of using the stack
• Baedert told the Inkscape devs that GtkStack has always had poor performance and they're not going to fix it.
• The app currently has 11 'pages' in the stack because of how Baedert first wrote Corebird (twelve once you count the "imposter" widget that he uses to fake moving from one type of page to the same page)
• I've seen no documentation on the overhead or side-effects of adding and removing widgets vs hiding them, so I don't know whether doing something "more sensible" by having fewer pages and adding them when required will make things better or worse

[alice-mkh]

I see; CSS invalidation would be the case with anything really. The only way to avoid it is to actually unparent the pages that aren't active and keep only 1 page in existence (or 2 if you're doing a transition).

So tldr your problem here is not stack, it's that you have quite a lot of widgetry that all exists at the same time. E.g. if it would be in a gtkbox or whatever, it would be same.

[CodedOre]

So, I have created two issues for the "Unread Items" counter, one for GTK and one for libhandy.

[philipzae]

Didn't see a mockup for quoted tweets and wondered how you planned to have that look, as the current design needs improvement. Also will the ability to quote retweet be similar to twitter, where when clicking the retweet button, you have the option to retweet or quote retweet?

[CodedOre]

Didn't see a mockup for quoted tweets and wondered how you planned to have that look, as the current design needs improvement.

I do have an idea, but not in form of an mock-up.

Also will the ability to quote retweet be similar to twitter, where when clicking the retweet button, you have the option to retweet or quote retweet?

That would actually be my preferred option for implementation.

[IBBoard]

Is the "kebab" menu button only going to be in the TweetInfo view? Or could we keep the current approach and have a "more" menu item that's next to the other actions? That would let us put the translation, delete and quote tweet in there without adding an extra step for "I want to just RT this".

Or we go less discoverable and do the popup unless some modifier key is pressed - Ctrl+Click for vanilla RT? Or Shift?

And unrelated, I'm wondering whether we should have numbers next to the RTs etc in the main timeline. 1) it's visual clutter, 2) we'll never update them (TweetInfo at least reloads that data each time you return to the page) and 3) Twitter already looked at hiding them in the main timelines to improve social media "health" (and we don't show them in timelines now)

[philipzae]

Is the "kebab" menu button only going to be in the TweetInfo view? Or could we keep the current approach and have a "more" menu item that's next to the other actions? That would let us put the translation, delete and quote tweet in there without adding an extra step for "I want to just RT this".

The 'more' menu item seems quite unnecessary when there is so much room available to show all the actions. If merging the retweet and quote tweet is disliked, then we simply have a button for it with a speech bubble icon for quote tweet.

And unrelated, I'm wondering whether we should have numbers next to the RTs etc in the main timeline. 1) it's visual clutter, 2) we'll never update them (TweetInfo at least reloads that data each time you return to the page) and 3) Twitter already looked at hiding them in the main timelines to improve social media "health" (and we don't show them in timelines now)

I found it strange that cawbird didn't do that in the timeline, mainly as I don't want to have to click twice or thrice to do any of the actions. For me that is most important to my UX of the app and seeing the numbers is less important, but maybe have them hidden by default and give users the option to turn them on in settings.

[IBBoard]

I'd rather not add too many options. And having buttons that may or may not include numbers of varying lengths just messes with the visual consistency. We'll keep it to the Tweet Info page for users who care, and colour code the action buttons as to whether the user has used them, the same as we do now (but on the hidden right-click panel)