Remove/replace placeholders in Cristal

[pjeanjean]

Hello,

Right now, Cristal still renders some placeholders at various places. The point of this proposal is to list the ones we can do something about, and decide what to do (depending on the selected backend) before we can release a proper demonstrator:

1) “Page creation” button in the breadcrumb

This “+” button has always been there and never actually used. We already have a button to create pages in the sidebar, which opens a form to input the name of the page and select its location through a navigation tree.
AFAICR we have never really discussed the point of this button, and I think it’s supposed to become a “quick create” operation in the current location. As such, I see two possibilities:

• a) When clicked, it would be replaced with a text input field to set the name of the page, with a small submit button on the right. Confirming would simply open the editor, like we do currently with the other page creation button.
• b) Remove it.

2) “Likes” and “Comments” counters

These two features are not yet implemented. In the meantime, we can either:

• a) Set the counters to 0 (which would still make them inconsistent with the actual values from the backend).
• b) Add a enabled() method to InfoActions to simply hide them. I believe we will want this in the end because I don’t see a point in displaying these two with the FileSystem backend.
• c) Remove them.

3) “Last edit” details

This is not hard to actually implement right now, except we still don’t have user icons. Also, I’m not sure the username is relevant with FileSystem. I see a few possibilities:

• a) Implement it for every backend (we would use os.userInfo() to get the local user for FileSystem) and keep the placeholder avatar.
• b) Same, but remove the avatar.
• c) Same as above, but only keep the “Edited on” part for FileSystem.
• d) Remove it.

4) “Information” tab

There are not a lot of information we can display at this point, but we could:
a) Add the creator and creation date, and display the page reference (like we do in XWiki), for every backend.
b) Same, but removing the username for FileSystem.
c) Remove it until we have more useful information to display.

5) “Help” button in the sidebar

I’m not sure what was expected with this one, since it says explicitly “XWiki Help”, but I can see a few outcomes:
a) Rename it “Cristal Help” and have it open the Cristal “user guide” documentation.
b) Rename it “Cristal Help” and open a modal (but we need to decide on the content to put in there).
c) Remove it.

6) “Wiki Name” in the sidebar

We still do not support multiple wikis, and some backends simply do not have this concept. We could:
a) Still use the name of the wiki when applicable, and have specific names for, e.g., FileSystem and Nextcloud (for GitHub, it could be the current branch name?).
b) Only display it with the XWiki backend.
c) Replace it with the name of the current configuration (or a “wikiName” property set in the configuration).
d) Remove it.

---

Note that in all the options, choosing “Remove” will simply mean that I will create an improvement issue to put the element back in the future. There are also other placeholders (such as the search box) that will simply be removed because there’s nothing we can do without an actual implementation.

My votes would be:

1. a
2. b
3. c
4. b
5. a
6. c

WDYT?

[mleduc]

I’d propose a different strategy:

1. Remove every element you identified
2. For each removed element, create an improvement issue to introduce it back (if it does not already exist)
3. If you have some time left at the end of the roadmap, take some elements and start handling them.

[tkrieck]

On my part, if you want to do it in this roadmap:

1. a
2. b
3. b (Avatar comes in the future right?)
4. b
5. a
6. c

But I am not against @mleduc take also, depends on the time you have available.

[pjeanjean]

I can definitely do that for the current roadmap, but I think some of the points I raised are still worth considering here.
For example, if I remove the Information tab now, when will we consider that we have enough data to put it back? What should we do in the future for the backend-specific elements? And should the avatars be a hard requirement to put back some removed elements or can we do without?

Let’s consider this post as brainstorming for the (near) future instead

[mleduc]

@tkrieck

b (Avatar comes in the future right?)

The needs emerge to have a uniform way to display users inline:

1. with a “nice” name instead of the user identifier (i.e., Manuel Leduc instead of XWiki.mleduc)
2. with a link to the user’s profile page if it exits
3. with an avatar

I’ve introduced the user extension in 0.12, but it is currently missing points 1 and 3.

[mleduc]

@pjeanjean

Let’s consider this post as brainstorming for the (near) future instead

I think we’d be better off with separate discussions for each topic.
Otherwise, this discussion will quickly be very messy, as afaics most of them deserve a proper design and proposal before starting implementing them.

[vmassol]

@mleduc

I’d propose a different strategy:

1. Remove every element you identified
2. For each removed element, create an improvement issue to introduce it back (if it does not already exist)
3. If you have some time left at the end of the roadmap, take some elements and start handling them.

Definitely +1 from me, we need to remove these placeholders first (and ASAP), and once it’s done talk about the future. So that we can release a Cristal version we can put in the hands of users to play with/experiment.

I mean it’s fine to talk about it now but have they been removed in the meantime? I don’t want this discussion to postpone/block their removal.

Thx!

[pjeanjean]

I went with removal for most, and I will open single topics to discuss designs when the initial PR is merged.
Right now though I’m still unsure about 5 and 6:

• I still think there is some value in having 5.a for a first usable release, rather than no button at all.
• I consider 6.c to be more sound than a panel without any title (though we only have a single panel right now, so the user might not even see it as one if we just remove the title).

Some feedback on these two would be great, and afterwards I’ll close this post and open the appropriate ones.

[mleduc]

@pjeanjean

I still think there is some value in having 5.a for a first usable release, rather than no button at all.

I don’t see anything vital to have a help button. A good UI shouldn’t require external help to be usable.
And, here too, a proposal is required. For instance, do we want to embed the documentation to make it accessible offline, or do we want to link to an external documentation?
Therefore, I’m still +1 to follow the same strategy and remote it first, and add a good implementation later.

@pjeanjean

I consider 6.c to be more sound than a panel without any title (though we only have a single panel right now, so the user might not even see it as one if we just remove the title).

I’m fine with no title at all for now, as I don’t think this information is useful as of now (unless I’m missing something?).
Or, if we think this information is important, we need to make it clear that this is about the currently selected configuration.