-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert message list to new, 2023+ design #157
Comments
If confused about anything or willing to simplify design because of any reason please tell me and I try my best to help |
A note for when we take this on: I think it will make sense to pursue both the light theme and dark theme at the same time. That's because I think that when we're in the midst of doing that reverse-engineering work described above, it will be relatively little work to include the dark-theme version of a given area of the design in addition to the light-theme version, compared to the work that would be involved to complete the reverse-engineering for one theme and then at some later point come back and get back into the reverse-engineering to take care of the other theme. In the code, this probably means:
|
Ah, and thanks to @sirpengi for locating the zulip-mobile issue where @terpimost previously walked through a mobile version of the new design for the message list: So I think that design is the place to start from. For all the details it doesn't cover, we'll fall back to reverse-engineering web as described above. Here's also @terpimost's Figma design for the message list: |
This is a small change in line with zulip#157 and moves the implementation closer to the new 2023+ design for mobile. Messages now span from screen edge to screen edge and borders around groups of messages (in particular the left-side recipient border) was removed.
This is a small change in line with zulip#157 and moves the implementation closer to the new 2023+ design for mobile. Messages now span from screen edge to screen edge and borders around groups of messages (in particular the left-side recipient border) was removed.
This is a small change in line with zulip#157 and moves the implementation closer to the new 2023+ design for mobile. Messages now span from screen edge to screen edge and borders around groups of messages (in particular the left-side recipient border) was removed.
I've just filed two sub-issues of this: which we'll want for the upcoming Beta 1 milestone. We'll pursue the rest of this for Beta 2. |
Values obtained by looking at the "Computed" tab in the Chrome DevTools element inspector, on CZO at 8.0-dev-2850-gef1c1ce05f. Technically the web app has a computed `line-height` of 16.996px, but that seems like a rounding error. One reason for doing this now is to opt out of a default that would take effect with the upcoming migration to Material 3. The text would otherwise get a line height of 1.43 times the font size, and we want it to be denser than that. We briefly explored how to preserve the line height exactly, across the M3 migration, but the solutions we found seemed more awkward than just taking care of this now: zulip#380 (comment) Fixes-partly: zulip#157 Fixes-partly: zulip#294
Values obtained by looking at the "Computed" tab in the Chrome DevTools element inspector, on CZO at 8.0-dev-2850-gef1c1ce05f. Technically the web app has a computed `line-height` of 16.996px, but that seems like a rounding error. One reason for doing this now is to opt out of a default that would take effect with the upcoming migration to Material 3. The text would otherwise get a line height of 1.43 times the font size, and we want it to be denser than that. We briefly explored how to preserve the line height exactly, across the M3 migration, but the solutions we found seemed more awkward than just taking care of this now: zulip#380 (comment) Fixes-partly: zulip#157 Fixes-partly: zulip#294
Moved widgets around such that the gutters to the left and right of message contents are ready for future decorative elements. Fixes-partly: zulip#157
Moved widgets around such that the gutters to the left and right of message contents are ready for future decorative elements. Fixes-partly: zulip#157
Moved widgets around such that the gutters to the left and right of message contents are ready for future decorative elements. Fixes-partly: zulip#157
Moved widgets around such that the gutters to the left and right of message contents are ready for future decorative elements. Fixes-partly: zulip#157
Adjusted a test that was broken by the layout change. Fixes-partly: zulip#157
By wrapping the icon with a dummy Text widget in a Row, the Text helps us stretch the row to the same height as a line of a message content would have. This allows us to position the icon with respect to text, even if a scaling factor has been applied. Fixes zulip#157. Signed-off-by: Zixuan James Li <[email protected]>
This umbrella issue has already been partly split up into individual issues. The next step is to finish doing that, and close the umbrella issue so we can track the individual pieces separately. |
We've resolved quite a lot of the content of this umbrella issue already, as seen in the backlinks above from numerous issues and PRs. I just made a pass through the code mentioned in the description:
and also looked around the message list in the live app to look for anything that seemed like the old design. I think at this point there's only a few pieces of this umbrella issue that remain open. Those are:
Also related are:
With that, I'm closing this umbrella issue. |
In the current prototype, the visual design of the message list is based closely on Zulip web's design as it was last December, when I started on the prototype and wrote most of the code we have for that so far. This also makes it broadly similar to the zulip-mobile RN app, which uses a design based on the same generation of Zulip web's design.
Since then Zulip web has undergone a substantial redesign, to designs by @terpimost:
https://blog.zulip.com/2023/05/31/zulip-7-0-released/#redesign
and some of the major changes there are in the message list. Among them:
We should target the new design, instead of the old.
Probably the way to do this is to basically go from scratch, rather than incrementally modify the existing design. (This is one advantage we have as a prototype compared to making the same change in web.) That means:
widgets/message_list.dart
andwidgets/content.dart
where we're controlling styling and layout, expect to rip that code out and replace it with newly-written code. (On the other hand, the code that's about finding appropriate data to show, or walking aContentNode
tree, should mostly not need to change for this.)We won't want to match web's design exactly:
The text was updated successfully, but these errors were encountered: