Right now EchoEventPresentationModel::getSecondaryLinks() returns array( url => text ). @Legoktm, how do you think this could best be extended to add more information like an icon and a subtitle?

Is the subtitle different from the currently unused text?

Something like:

		return array(
			'url' => array(
				'text' => '...',
				'icon' => '...',
			)
		);

I suppose. If we do that though, I'd rather do it sooner rather than later to avoid needing b/c code or having a b/c break.

In T115421#1760941, @Legoktm wrote:

Is the subtitle different from the currently unused text?

Yes. The currently unused text is for the primary link (I'll file a task about killing that); this is about secondary links.

Something like:

		return array(
			'url' => array(
				'text' => '...',
				'icon' => '...',
			)
		);

Looks good to me. Should we keep the URL as a key, or should we make everything a value?

I suppose. If we do that though, I'd rather do it sooner rather than later to avoid needing b/c code or having a b/c break.

I guess if we keep the URL as a key, we could implement b/c easily by interpreting array( 'url' => 'text' ) as shorthand for array( 'url' => array( 'text' => 'text' ) ).

secondary items need to specify an icon, text for their subtitle/tooltip (depending on rendering mode), and whether they are rendered outside the 'more' menu ("explicit") or inside ("implicit").

For representation purposes we probably need three items: icon, label, and description (which will be rendered as a tooltip or a text description depending on whether the item is presented inside or outside the "more menu"). In addition to that, I guess we need a way to express the action itself which a URL seems a valid approach for.

Also, the rules for deciding whether to represent the items inside and outside the "more" menu are more a system decision than decided by the individual items. For example, a given notification that shows two actions and a "more" button by default, will show all those actions inside the "more" menu when this notification is part of a bundle (i.e., it is presented in a more compact way).

The way I see this is that the notifications bring a list of actions, depending on the room we gave for actions, the first 1-2 of them may be presented directly to the user and the rest inside the "more" menu. the system may add some generic actions to the list but those will be always provided as part of the "more" menu.

In T115421#1761196, @Pginer-WMF wrote:

secondary items need to specify an icon, text for their subtitle/tooltip (depending on rendering mode), and whether they are rendered outside the 'more' menu ("explicit") or inside ("implicit").

For representation purposes we probably need three items: icon, label, and description (which will be rendered as a tooltip or a text description depending on whether the item is presented inside or outside the "more menu"). In addition to that, I guess we need a way to express the action itself which a URL seems a valid approach for.

Yes, sorry. I forgot to mention the label and the URL because we already have those.

Also, the rules for deciding whether to represent the items inside and outside the "more" menu are more a system decision than decided by the individual items. For example, a given notification that shows two actions and a "more" button by default, will show all those actions inside the "more" menu when this notification is part of a bundle (i.e., it is presented in a more compact way).

The way I see this is that the notifications bring a list of actions, depending on the room we gave for actions, the first 1-2 of them may be presented directly to the user and the rest inside the "more" menu. the system may add some generic actions to the list but those will be always provided as part of the "more" menu.

Yeah, what I meant was that we should have a way to distinguish between items that are always in the more menu vs items that can possibly be outside of the more menu.

I'm working on the notification demo for the new design, and with it, a new schema for the API. My idea for secondary links was something like this (as an API response) :

		"secondary": [
			{
				"iconType": "user",
				"label": "Cronopio",
				"url": "http://en.wikipedia.org/wiki/User:Cronopio"
			},
			{
				"iconType": "talk-flow",
				"label": "View the topic",
				"url": "http://en.wikipedia.org/w/index.php?title=Topic:Sra19tlcuba4huvd"
			}
		]

This way, we can control the icon types as well, if needed. If there's no icon we can send a 'null' or 'false' value.

Change 254147 had a related patch set uploaded (by Matthias Mullie):
Add secondary link details: icon & description

https://gerrit.wikimedia.org/r/254147

The primary link currently also has an associated text, which is not displayed in the flyout or the special page.
I assumed it wasn't used and wanted to get rid of it, until Stephane pointed out it is used in the notification emails.

Do we still plan to include a text label for primary link in emails? And if yes: will we also want an additional description & icon?

Change 254147 merged by jenkins-bot:
Add secondary link details: icon & description

https://gerrit.wikimedia.org/r/254147