User Action Menu in Small Viewports

[ColinJM]

1) I have created a forum and many of my members are no that computer savvy.
2) As a retired website designer I try to make my menus as intuitive as possible.
3) SMF generally has very good navigational architecture.
4) However, in resect to responsive adaptation in small viewports theUser Actions button menu has NO ALERTS OR EMAILS :



May I suggest this sub menu item should be modified to read just ALERTS OR EMAILS

[Diego Andrés]

No Alerts or Emails refers to disable either that is enabled, so Alerts or Emails would be the opposite, no?
The opposite would be the last option which is Receive Emails and Alerts.

It did seem confusing the first couple of times I used it.

[ColinJM]

Thanks DA for your input - which I find a bit confusing to be honest. I'm still of the opinion that Emails and Alerts would be better item title - then you click on that and select one of the 4 options.

[Tyrsson]

Thanks DA for your input - which I find a bit confusing to be honest. I'm still of the opinion that Emails and Alerts would be better item title - then you click on that and select one of the 4 options.

It's one of those things where you have to take the entire context into consideration. This one template or template section provides all of the functionality that you are describing without the need for more markup.

[ColinJM]

Thanks DA for your input - which I find a bit confusing to be honest. I'm still of the opinion that Emails and Alerts would be better item title - then you click on that and select one of the 4 options.

It's one of those things where you have to take the entire context into consideration. This one template or template section provides all of the functionality that you are describing without the need for more markup.

Ok - thanks for the input - but I still feel that No emails and Alerts in the menu title leading to the tertiary level menu is unintuitive and gives the impression it's setting no alerts or emails rather than a drop down to the four options.

[shawnb61]

That particular menu entry is a little confusing, because it doubles as a display of your selection.  The benefit is you don't need to click on it to see your setting for that board or topic.  Your setting is already displayed.  Change it & see.

[Antechinus]

Ok, read all of that. Can see the point, but honestly it's the most counter-intuitive way possible of designing a menu, Someone "clever" has obviously "put a lot of thought into this", instead of just doing something normal people would do. Hence the issue described by the OP.

Shades of the 2.1 attachments system here. Highly technical overthinking, resulting in something normal people won't want to use.

The header should be a standard header for that section of the settings menu. The actual settings should be within that section. If you do it that way, no confusion. HTH.

[ColinJM]

That particular menu entry is a little confusing, because it doubles as a display of your selection.  The benefit is you don't need to click on it to see your setting for that board or topic.  Your setting is already displayed.  Change it & see.

Hi Shawn,

I did - and it didn't change.

[Diego Andrés]

Works well for me on this site/topic. You should see the indicator on the page when clicking an option (an least on desktop), and it should update the button title accordingly.

In my themes I changed this behavior to simply display Notify (means either is off) or Unnotify (means either is on) and open the dropdown for more specific information.
The wording is something to discuss for any scenario for sure.

Ok, read all of that. Can see the point, but honestly it's the most counter-intuitive way possible of designing a menu, Someone "clever" has obviously "put a lot of thought into this", instead of just doing something normal people would do. Hence the issue described by the OP.

I'd agree that putting this button with a simpler style in the topic header instead of buttonlist would be not only cooler but more relevant. Other than that I disagree, all of the options are meaningful and relevant to the user.
 

[Antechinus]

That particular menu entry is a little confusing, because it doubles as a display of your selection.  The benefit is you don't need to click on it to see your setting for that board or topic.  Your setting is already displayed.  Change it & see.

Hi Shawn,

I did - and it didn't change.

My suggestion (based on long experience): don't bother arguing with the team about it,and just recode it to suit yourself.

[ColinJM]

My suggestion (based on long experience): don't bother arguing with the team about it,and just recode it to suit yourself.

I was arguing , merely exchanging a different view point that my Users raised and I agree. But yes, I take your point  - where do I change itplease @Antechinus ?

[Antechinus]

That's odd. I just ran a recursive search on the whole 2.1 install pack, and the only place that text string is found in in the language file itself. And yes, obviously I also checked for the code to call the actual text (ie: $txt['notify_board_1'] and $txt['notify_topic_1']). Those variables are not found in any file except index.english.php.

So... somehow they are being called in a sneaky manner. Not sure how, but someone will probably know.

[ColinJM]

That's odd. I just ran a recursive search on the whole 2.1 install pack, and the only place that text string is found in in the language file itself. And yes, obviously I also checked for the code to call the actual text (ie: $txt['notify_board_1'] and $txt['notify_topic_1']). Those variables are not found in any file except index.english.php.

So... somehow they are being called in a sneaky manner. Not sure how, but someone will probably know.

Well thanks for your efforts anyway Ant...

[Antechinus]

Aha. Found it. Sources/MessageIndex.php (also Display.php and Recent.php).

Code Select Expand

if ($context['can_mark_notify'])
$context['normal_buttons']['notify'] = array(
'lang' => true,
'text' => 'notify_board_' . $context['board_notification_mode'],
'sub_buttons' => array(
array(
'text' => 'notify_board_1',
'url' => $scripturl . '?action=notifyboard;board=' . $board . ';mode=1;' . $context['session_var'] . '=' . $context['session_id'],
),
array(
'text' => 'notify_board_2',
'url' => $scripturl . '?action=notifyboard;board=' . $board . ';mode=2;' . $context['session_var'] . '=' . $context['session_id'],
),
array(
'text' => 'notify_board_3',
'url' => $scripturl . '?action=notifyboard;board=' . $board . ';mode=3;' . $context['session_var'] . '=' . $context['session_id'],
),
),
);
God knows what they have done to turn that into the section header on mobile.

[Kindred]

The text changes to the current setting...as Shawn said it should

You don't want to change the notify_board_1 text string, since the also controls the setting itself and not just the heading which shows the current setting value

[Antechinus]

Yes, we already know that, but the point is that his users are finding the default behaviour confusing, so the OP would like to recode it to have a normal, static section header. Which is perfectly fine, IMO. Obviously it will require using a different language string for the static header, but that's not a big deal.