Logo management UI Revamp

Development
1

Hello everybody! :hugs: Let’s discuss the way users change or upload logos.

  • Issue #1: Users find it hard to identify from where to change the logo.
  • Proposal #1: Change the location of this UI to make it easier to reach.
  • Issue #2: We do not have a global UI for changing skin logos and theme logos.
  • Proposal #2: Have a single source of truth for logos (where you can upload, view, change, edit)

What we currently have

The user’s flow to get to change a logo in xwiki is:

Global Admin > 1) Look & Feel > 2) Themes > 3) Customize theme > 4) Choose an attachment > 5) Actions around logo (at least 6 clicks)

From our previous UI/UX designer Ecaterina’s usabilty session:

Average time for “Change Logo” task, for beginner users, during our Scenario #6 usability session was 7 minutes. This period is very high, especially for such a common task. This length causes abandonment and frustration.

journey to change logo.png
journey to change logo.png4870×1783 530 KB

What we should have

A logo space where each Logo added has different properties.

These properties reflect where the logo should be used (which skins, which themes, if it’s a default logo or not).

From where to enter the logo management page

The logo management UI could be entered from:

  1. the Themes section, right at the beginning before customizing themes.
  • Pro: less changes to documentation
  • Con: less improvement - this version’s journey has more steps than version 2 and its success depends on the user’s belief that in Themes he will find the functionality of changing the logo. (GA > Look & Feel > Themes> Change logo)
  1. a sub-section of Look and feel, before Themes
  • Pro: simplifies the journey (3 clicks: GA > Look & Feel > Change logo)
  • Con: more changes to documentation

Version 1

logo change 12.png
logo change 12.png2704×1038 221 KB

Version 2

In this version, we’d have a new section in Look & feel, named Change logo.

Clicking the Change logo link will lead to the logo management page presented in the next section.

In this version, the logo management page will be part of the Change logo section, NOT the Themes section.

logo chaneg 0.png
logo chaneg 0.png2674×1123 289 KB

The logo management Page

Regardless of where and how we access it, the following management page will be shown:

logo change 22 icons with labels.png
logo change 22 icons with labels.png2704×1361 299 KB

This page has:

  • an upload button for a new logo
    • this would open the file explorer, letting the user choose a logo from their computer
  • a list of all uploaded logos with all their properties and actions
    • If the logo is NOT enabled as a default logo, that checkbox and its label are NOT shown

Clicking the edit icon would open a configuration modal (see next section).

Settings for logo

Clicking the edit icon of a logo would open a modal with all the configurations made.

logo change 4.png
logo change 4.png2704×1394 315 KB

  • The Usage on themes and Usage in skins field use the multi-select component (example of look somewhere else in XS: selecting multiple users in an AWM). The user can choose from a dropdown with all possible items, the themes/skins that he wants.

Logo priority

  • Theme logo > Skin logo > Default logo
    • If the theme logo is defined, it replaces the skin or default logo.
    • If the skin logo is defined, it replaces the default logo.

What to do with the old UI?

I think that once we implement this new proposal, the old UI shouldn’t exist anymore, keeping one single “source of truth” for this functionality.

What do you think of all this?

2 Likes
2

Thx for looking into this, it’s a very important topic and I completely agree with you (and with Caty) on issue #1 that we’re not good-enough in the UX of changing XWiki logos.

I think we currently have several ways to change the logo and more just one:

  1. the one you mentioned from the Admin UI to change the theme (global level)
  2. by changing the logo in the Skins (global skin, space skin, skin of the user), see the logo xproperty in https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Skins#HChangingtheSkin
  3. in the color theme but for a specific space only.
  4. (technical) with Very basic question: changing logo - #5 by pjeanjean or by using xobject editors in general

Other problems to solve ideally:

This is to say that in your proposal you need to take into account:

  • what logo the user wants to change: the global one, a space logo, a page logo (maybe even a specific logo for a user - for ex if we want to allow a theme selected for a user in the future)
  • differentiate between skin logo and color theme logo. Either propose to drop the concept of logo for a skin or the color theme logo should override the skin logo (color themes apply on top of skins).

I see you’ve mentioned “if it’s a default logo or not”. WDYM by a default logo? Is it the default skin logo (ie when logo is explicitly defined for a skin)?

EDIT: I see that in the " What we should have" section you do mention skin logos vs theme logos. I found it strange that you didn’t mention this in the " What we currently have" section. I still think you’re missing the concept of wiki logo vs space logo vs page logo (vs user logo in the future if we implement user themes).

I think you mean removing the UI for:

  • logo xproperty in the edit sheet for a skin
  • logo xproperty in the edit sheet for a theme

Is that so?

Technically we’d still need to keep the various logo xproperties.

Side note: I think that we should consider skins as some advanced topic, and thus hide it more vs themes, so that users are less confused.

  • If the logo name is changed, does it mean that the logo attachment is renamed?
  • I’m not sure I understand what is a defaut logo. If you’re talking about a default skin logo, I don’t think we can change that, it’s supposed to be fixed/hardcoded.

Technically I guess this could be implemented as a LiveData with a card layout.

Shouldn’t we highlight the logo used currently (ie for the current skin and current theme)? In your example there are several logos set for Flamingo skin, but only a single logo can be set for a skin, is that just a mistake of the example?

I like the idea of a single place with a global overview for the logos.

I’m assuming that in your proposal the same UI would exist at the level of space admin and page admin. But then, users will not have a global view of why a given logo is displayed or not displayed at a given location in the wiki. Is this a problem?

I find it a bit weird that we’d essentially remove ability of setting the logo for a skin or for a theme when editing the skin or the theme.Then we offer a single UI but then when adding a logo you have to decide if it’s a theme logo or a skin logo. So users need to understand the concepts of theme logo vs skin logo.

Let me play the devil’s advocate (for the sake of discussion): How is your UI simpler than what we have now? For me, the proposed UI is quite more complex as you need to understand the concepts of skin logo, theme logo, etc. whereas right now you just go to the L&F > Theme UI and change the logo there for the selected theme. What’s complex right now is the skin concept since you can also change the logo there and users may be confused. But if we “hide” the skin as something advanced, maybe it’s less an issue?

Global Admin > 1) Look & Feel > 2) Themes > 3) Customize theme > 4) Choose an attachment > 5) Actions around logo (at least 6 clicks)

With your proposal, it’s:

*Global Admin > 1) Look & Feel > 2) Themes > 3) Logos > 4) Click upload logo > 5) Fill “usage of themes”, fill “usage in skins”, click “submit”.

That’s at least 6 clicks (and possibly 8). So the same in term of complexity…

I need to think more about this but I’m curious to see the feedback of others.

Ludovic also mentioned, as an idea, that we could have a DW step to let the user select a logo since it’s a very common task that almost everyone needs to do when you set up a wiki. This is separate from this proposal but it’s related so I thought it should be mentioned. If we have this then the need to change the logo and finding how to do this is a bit less needed.

Thanks a lot for working on this topic and making a proposal to make the topic progress! :slight_smile:

1 Like
3

If we rely on this knowledge, we might as well set the logo as a subsection of the Color Theme section (or just one item in the list of fields if we just want one button to access the full Logo UI).

There’s already 9 subsections there, which is already the top range to fit Miller’s low. Adding an additional item here would put us to 10. It’s not an easy change so I can’t say it’s not the right version because of this, I just want to point out this small loss for version 2.

I think that in order to fit better with other section names, we should name it with a noun only, something like Logos.

Overall:

  • I’d be in favor of dropping Skin logos from this UI. In practice the majority of users will only ever need ColorTheme logos. We can save on at least a couple clicks in the logo creation/edition form if we remove this.
  • The old UI should still be there IMO. The concept of logo is very related to the concept of colorthemes so it wouldn’t make sense to not show it (even more so because it’s already here so it doesn’t take time to setup :slight_smile: ). Old users might also find the new UI more complex than what they got used to (setting an image as a logo for one colorTheme from the colorTheme edition UI).
  • Do we display unused logos in the new UI? As far as I can see, unused logos are displayed for each colorTheme on their own editors. It could be interesting to keep track of all uploaded logos. If not, it would mean that changing the logo to something else should always delete the old logo, which is not currently the case.

Thanks for the time you spent on this topic!
Lucas C.

4

Hi! Came back on this proposal with some new ideas.

In this new version we’ll have an UI for 3 cases of logos:

  • logo affecting current location
  • logos affecting other locations
  • unused logos

The following example is based on a wiki with its homepage named Marketing. :star:

How would the user access this UI?

  • Through Page/Wiki/Global Administration
  • Part of Look & Feel > Themes > Color theme

ui location
ui location2674×1213 316 KB

Entering the UI (inital state)

  • Only the current location section is expanded. The rest are collapsed.

logo change4 initial
logo change4 initial2704×1397 292 KB

Expanded sections

logo change4
logo change42704×3000 494 KB

Buttons

  • Change button - opens a modal with configurations to the current logo and the option to upload a new logo. Uploading a new logo sends the previous one in the Unused logos section.

  • Upload new logo - opens modal to upload a logo and set a location that is affected by that uploaded logo

  • Delete button - forever deletes the logo

  • Use button - opens a modal to use the logo somewhere (the user will set the location affected by the logo eessentially

Modals

I will go in more detail on the opened modals if the layout is closer to what many people would like

WDYT?

@CharpentierLucas , @vmassol , @tkrieck & everyone else coming to this thread

5

I’m wondering if the info about the current UI isn’t missing from the UI itself.
For pages, this info is usually contained in the breadcrumb (makes it easy to understand the path we took to get to the current page, or at least how it’s possible to get back). This is the way to make sense of what’s happening exactly when we click on the customize button of the colorTheme section.
For administration sections, this same information is contained in the state of the accordion. The current section is highlighted. It gives me a clear indicator of how to get back.

IMO we’d want either:

  • the UI you showed contained in its own page, probably something like XWiki -> Global Administration -> Logo Administration
  • OR the UI you showed directly in the Color theme section.
  • OR we add another level of sections in the Admin accordion (probably not this one though, feels surfeit).

Without any of those, I fear the experience might be a bit confusing.

  • IMO the dropdown toggles should look smaller, to be consistent with other similar elements in the UI.
  • Location affected, Theme used and Logo used are very verbose and could probably be simplified to Location, Theme and Logo. If needed for clarity, nothing prevents us from adding a line before the table to explain clearly the meaning of the columns.
  • Why are the Logos on a grey background? If we want a colored background (I guess it’d be to highlight non semi-transparent logos), we can just use the one from the navbar.
  • For the unused logos, the first two columns are always useless as far as I understand. We could just remove them. I think the inconsistency between the table columns is worth the simplification.

Thanks for updating the proposal!
Lucas C.

1 Like
6

I think this option works well, good catch

good points, thanks a lot

this was my initial idea, but I was wondering about the pretty-niche-case of having the navbar white (or the same color with the page’s background).

fair, fair, I’ll update the proposal

Thanks a lot, Lucas! All of this is very helpful! :hugs:

7

Hi Adina, I liked the single management UI. Couple of things on my side:

  • How about dividing the UI into only two? One for logos being used and another for unused ones.
  • The current logo being used can be indicated by the text in the table (and maybe a bold style). Ex. “This Wiki”, “This Page”, etc.
  • I would also give priority to the image column, this way this is the first column visible on mobile.
  • We can add the default search box to each column, useful for large deployments.
  • Add the filename on each logo, useful for searching
  • As @CharpentierLucas suggested, we can simplify some terms, below are my suggestions.
  • Add a reinforcement tip to the user guaranteeing that the “Unused” logos are, in fact, unused and could be deleted.

“Very” visually appealing markdown mockup below:

Logos in Use

Logo Image Used in Theme Actions
[ Search ] [ Search ] [ Search ]
image
name.svg		 This Wiki Iceberg Change, Delete
image
name.svg		 Marketing Wiki Children Iceberg Change, Delete
image
name.svg		 Dev Ops Wiki Iceberg Change, Delete
image
name.svg		 HR Iceberg Change, Delete

Unused Logos
Tip: You might want to delete these logos as they are not used anywhere

Logo Image Actions
[ Search ]
image
name.svg		 Change, Delete
image
name.svg		 Change, Delete
image
name.svg		 Change, Delete

Thanks for the proposal =)

1 Like
8

We could use a checker box pattern for the transparency, like in Photoshop.

9

If the navbar is white, the user doesn’t have to care as much about logos having a white background instead of being transparent. Not sure where we use this logo if not in the navbar.

I just went to check in the codebase, it doesn’t seem like there’s another relevant template where it’s used.

I’m glad my comments were helpful :slight_smile:
Lucas C.

10

It’s not straightforward to do in CSS but it seems like it’s not that difficult to implement nowadays → CSS Checkered pattern that can be used on all modern browsers. · GitHub
https://codepen.io/sereza7/pen/VYwryav

1 Like
11

Nice to see that it can be done directly in CSS, but as a fallback we can always use an SVG or PNG background that is repeated in a container element.

12

About:

And

What’s not clear to me is what you’re suggesting the user will see in the different cases: Page admin, Wiki Admin, Global Admin and Global Admin on the main wiki (for farm admin).

For example, it wouldn’t be logical to display logos used on other pages from a specific page’s Page Admin UI. First, because the user may not have admin rights for the other pages so you shouldn’t be able to display the choices made there, but also because all the admin UIs only show what’s relevant for the current admin location (eg you cannot change a global skin if you’re on a given page’s admin UI).

Also note that the main wiki is a special case if we want to see or set logos used by other subwikis. You wouldn’t be able to do that from a specific wikis for the reasons mentioned above but if we think it’s needed, we could have it in the main wiki’s admin UI.

Thanks!