I suggest you stop using Discourse altogether then, because this is going to be the new default. I am sympathetic to the argument that when notifications arrive we should force the notifications version of the header on top, though.
With the new swipe left for hamburger, swipe right for notifs on meta it’s perfect. The access to notifications was the only downside, but with the latest modifications, it’s fine
Isn’t that true for your point too though? Whether or not something should be a setting vs an edict is also matter of opinion, not some objective truth.
Despite the pain, it may actually be better in the long term to retrain Discourse users to not expect notifications to be visible everywhere and all the time, vs allowing them an option to opt-out of this change in ux direction.
In this regard, providing an option might even be a bad thing, depending on Discourse’s goals.
With all that said:
This sounds like the best of both worlds; updates when they happen, but otherwise out of your way.
نعم. من الجيد في الرأس الجديد أنه يوفر سياقًا و«صمتًا». بالتأكيد ستصبح ومضات الإشعارات مشتتة للانتباه. أنا سعيد بتقليل التشتت.
ملاحظات صغيرة
لكن التجربة على الأجهزة المحمولة تختلف تمامًا عن تجربة سطح المكتب:
- التمرير للأسفل ثم للأعلى قد يعرض حقل إدخال عنوان المتصفح بدلاً من (أو بالإضافة إلى) أدوات التنقل (أي أن السحر المتمثل في إظهار أدوات التنقل عند التمرير للأعلى ليس محصنًا ضد الأخطاء).
- النقر على العنوان
لا يملك أي تأثير (في سطح المكتب يعيدك إلى المنشور الأول)— المشكلة هي أن منطقة النقر صغيرة جدًا، وأصغر من ذلك في فئات الأسماء القصيرة مثل Development أو Contribute > UX.
أشياء جيدة
أثناء اختباري لكل هذا، اكتشفت:
- السحب من اليسار إلى اليمين لإظهار قائمة الهامبرغر، و
- السحب من اليمين إلى اليسار لإظهار قائمة الإشعارات.
ربما بالنقر…
ربما يجب أن يؤدي النقر على الرأس نفسه (أي عدم استهداف الهدف بدقة) إلى توسيع الرأس ليشمل القوائم و/أو توسيع منطقة النقر (باستخدام حشوة؟) حول عنوان الموضوع واسم الفئة؟ كما أن النقر على المنطقة العلوية اليمنى التي تكون فارغة دائمًا قد يكشف القوائم أيضًا.
ما زال ينقصنا حركة إيماء واحدة للبحث… (الضغط المطول على تلك المنطقة لإظهار البحث وتفعيل لوحة المفاتيح؟)، أو حتى أفضل:
A feature that involves tapping a blank space would be super odd, we should definitely not do that. Long taps (similar to left/right swipes) are already dedicated to browser features on iOS, so that’s out too.
Switching the header back when a notification comes in is probably the best option here (aside from not changing anything), but we just have to be careful to avoid having it flash in too frequently.
- Switch it upon notification until I start scrolling again
- Don’t switch it while I’m scrolling (if we’re hiding notifications on scrolldown this wouldn’t happen anyway)
- Add a small delay as a buffer? On mobile
scroll, stop briefly, scroll againis really common. So maybe we should wait a few seconds before switching the header out for a notification? Consider it a full stop instead of a rolling stop. - Add a small scroll buffer, so we’re not switching things back on tiny scrolls (I think we already do this)
I would be ok with this.
I’ve noticed that after following a notification on mobile, scrolling up does not make the menu appear again until you’ve scrolled up a fair distance, or until you scroll down then up again.
This breaks the flow of ‘check notification’ - ‘read’ - ‘go to the next one’.
And I’m sympathetic to the people who’d rather not have the header switch out when a notification arrives. It was tolerable to give people real-time notifications when a notification arrival just caused a small dot in your peripheral vision to appear, but switching an all-back title for a colorful logo all at the top of the screen would be impossible to ignore.
I’m sympathetic to people who want to be able to tell when a notification exists at a glance, but causing a fifth of your screen to change when you receive one is not acceptable.
Emphasis mine.
@ficuswhisperer I’ve seen you phrase this request as something for yourself a couple of times.
Is this a personal request, or something that’s come from your community such that it has enough volume to necessitate addressing it?
It might seem like pedantry, but it’s important.
Also, not to add to the list of things here.. But I wonder if an end (bottom) of topic notification area could work? Something for a UX person to chime in on maybe.
I think the header changing when you have notifications would be even more distracting, no?
Not sure why it matters, but I’m speaking for myself as a passionate user and I hope that I never said anything to indicate otherwise. That said there’s been forum admins in here also stating the same complaint.
It would be less distracting than having to scroll backwards through a thread at that I’m reading - and to make sure it’s done at a specific velocity otherwise it doesn’t register - until the top bar changes to check if I have any notifications.
I think it matters in terms of weighing the effort to change it vs impact it will have.
Maybe I’m just easily distracted… but I think that’s fairly common these days too.
I feel like this suggestion is the simplest resolution to all of the concerns raised so far, but it seems like it’s not being considered:
Am I missing something?
That.. would be an undesirable behavior? I don’t see that as a valid proposal. I see it as passive-aggressively asserting that the old header is “more important” than the actual topic header, which I vehemently disagree with.
Again, I am sympathetic to the argument that it makes sense to flip the headers around in a “just in time” manner when a notification arrives.
Please give me a little more credit than that.
I have wanted this feature for some time and still do: (per https://meta.discourse.org/t/show-topic-title-in-mobile-theme/13855). I’m still in favor of what exists today vs. what we had before.
The suggestion is not to throw the feature away, it’s just to try inverting which one shows up on scroll down, and which one shows up on scroll up.
As you’ve now made it clear that the suggestion has at least been heard, I don’t feel the need to advocate for it any more strongly.
I was just concerned that it had been overlooked.
I wasn’t referring to you, I was referring to the other person who originally proposed that specific idea.
I just feel like the amount of grounded axe here has reached peak so tempers are getting high.
I just wanted to re-assure you all here … I have read every single suggestion here multiple times and also am aware of all the suggestions
- Flip feature off per user @ficuswhisperer, wishes hopes and prayers
- Flip behavior around globally for the entire site (so you have to flick up to see title)
- Flip behavior around per-user
- Flip back to show notification when notifications come in
- Flip back to show notification when notifications come in, first time only (or only N times per minute)
- Display “tiny” circles for notifications, flags etc unconditionally
- Deal with it ™ which was also an axe we grounded
My plan remains… make a theme component you can use to “tweak per user as you see fit” if sites want to experiment with this then … go for it… I am not convinced I want to change any core behavior now.
I think we should do this one, it makes the most sense, and addresses the core complaint “I can’t see my notifications!”
I didn’t sense tempers flaring at all ![]()
Think this may be my first actual post here despite having read for a while now. Our community just got this change today and my initial reaction (and that of some other users) is very similar to the OP here.
I appreciate that changes like this don’t just come out of nowhere but I perhaps simply don’t understand what the issue at hand that lead to this change was?
And I don’t ask that in the expectation that anyone will/should explain themselves to me. Discourse is miles ahead of any other forum software I’ve ever used and I appreciate it’s a living, breathing, changing thing. I just don’t like this one and I think I should say that.
Sorry that my first post is a whinge…
Unpopular opinion but I like seeing the title of the topic I’m reading. As other posters said it’s easy to scroll up for the other header.
In theory you could allow admins to choose which header as a setting but that sounds like it could make the ui code a bit harder to maintain.
