elk Profile metadata design

I have been trying to find the rationale behind the profile metadata design, and I couldn't find any, so here are some thoughts.

Elk currently treats profile metadata in two ways, some items are shown as a list, while others are inlined and iconified in a separate block. This creates two classes of metadata items, one that belongs to a recognized category, identified by their distinct icon, and the rest.
Profile metadata is quite a remarkable space of expression. Customizable tabular information is unique in a social media profile, and we're already seeing many creative uses. We should rather encourage and promote this chaotic space rather than codify and dismantle.
A metadata field is iconified depending on its label. This enforces a certain format but also raises some further questions. The list of acceptable labels will likely be non-exhaustive, and may be misinterpreted. Why does "website" has an icon, but neither "web" nor "homepage"? Why does service X has an icon, but not service Y? Is the list of icon labels language-agnostic?
As the ordering of the items follows the metadata order, the icons themselves are shown in an inconsistent fashion, varying from profile to profile, making it difficult to follow and predict. Transforming tabular data into a list of inline items also makes it harder to read, and parse.
Having iconified items also raises the question of verified items. Should another icon be added in this flow of icons, which could make the list harder to parse?

I can see Twitter's inspiration, but the design that works with a single link and a rigid structure doesn't necessarily function with free and unpredictable information.

Proposition

My suggestion would be to entirely remove the iconified metadata list, and keep the labelled items, without substitution, as is. The "joined at" may either be left on its own, or moved elsewhere (top right?, in the dropdown menu?).

This being said, icons are valuable as they help recognition of a link source, especially since profile metadata are dense, and often contain multiple links.

We could add a favicon of the target website, after the link content, helping to quickly identify the source, without changing the nature of the metadata. Following these icons, we can also imagine verified links, which are currently not differentiated, to also have a check icon added, following the mentioned favicon. This configuration would allow recognition of the verification at a quick glance, the tick symbol, the favicon, and the link content being located alongside each other, something like: [label] | [link][favicon][verified-check].

As there might be some icon overload, so it might preferred to only show favicons when the associated link is verified. Another question is the credibility of favicons. Favicons are however trivially spoofable. Do we consider the combination URL/favicon/verification to be sufficient? An answer could be the use of Google Safe Browsing to exclude printing favicons for unsafe pages?

What are your thoughts?

Jan 13 '23 21:01 ksesong

Start a new pull request in StackBlitz Codeflow.

Jan 13 '23 21:01 stackblitz[bot]

Not a core maintainer, just was looking at a related issue and found this.

I do think there's value to the simplified icons for popular domains
- They add trust that when clicked the user will go to a non-phishing site as anyone can set a favicon to be the same as a well known domain, but they can't set the simplified icons.
- Favicons can be multiple colors and more than one format, breaking up the visual appearance. We can't make sites conform to our rules. Even using css filters to make them blend in better may be an accessibility issue.
Verified links should visually stand out more than unverified. Be it with a checkmark, or with a text color or background color difference or both. Text color or background if used should be a noticeable contrast difference from the unverified links.
Verified links should provide a screen reader friendly indication that the link is verified, so the benefit is not just for sighted users.
Perhaps icons should not be based on the label, but based on the domain name instead. This fixes an issue where someone could say "Twitter" then link to their personal site.
The Google Safe Browsing verification is a really good idea. Perhaps though instead of being tied to favicons, this feature should change a link's color and perhaps display an icon indicating "insecure". Clicking the icon or something could display an explainer to the user.
- taking the safe browsing idea a step further. (I would separate the development of this into a separate issue/pr). If the user clicks a link determined to be suspicious. Display a warning/confirmation before sending the user, so they are aware.

Jan 16 '23 23:01 TheWebTech

I agree with @TheWebTech. I think we should go further than we do with applying icons. I would be in favor of any metadata field that is a link that doesn't have its own icon having a link icon, and then displaying non-link metadata fields above them. I would also be in favor of a layout that still keeps each link's text label.

Roughly something like this:

Jan 17 '23 00:01 ZMYaro

Another potential solution would be to allow the user to decide how to format metadata, and to let them choose between Elk's style and Mastodon's style.

Jan 17 '23 06:01 gBasil

(Copy/pasting from #155) Since they are a little bit buried in the PR UI, here are some screenshots of what my current proposal looks like on a few profiles: