Extend the page Information tab

Hi devs,

In the context of in-place editing I created a proposal to extend the page Information tab with content from the edit panels. Basically this means exposing:

  • the page syntax
  • whether the page is hidden or not
  • the page locale, original locale and translations

in the page Information tab and to allow the user to edit this in-place. If you know other things that should be added to this tab please let me know. For instance I found:

Also, if you have any comments on the ordering of the information please reply.

Thanks,
Marius

+1 in general for having those info in the information tab.

Now in the screenshot of the design page there’s a pencil next to some fields in the information page: it means you allow the info to be edited there too? I’m mixed with this idea, since for me this tab was read-only.

Included pages is nice but a lot less than it used to be with the move to sheet system so would be nice to also indicate the sheet that was used to display this page.

Note: what is indicated as being the “Page reference” is actually the document reference, the Page reference syntax is different so it makes this information a bit misleading.

First of all, as I written in the design page, all the other tabs (comments, attachments, history) can change the document. Moreover, the fact that the Information tab didn’t change the document before doesn’t mean it cannot change the document in the future. I don’t see why you shouldn’t be able to modify some of the information related to the current page.

Note that modifying the information from view mode, from the information tab, is in-line with the goal of the 12.x cycle to make XWiki more editable in-place, right from where the information is displayed. Moreover, with the introduction of in-place edit in 12.3 the simple users won’t have access from the UI to the old Wiki / WYSIWYG edit mode so they need to have access to this page information and be able to change it.

Thanks,
Marius

Ha and I forgot the +1 for the proposal.

Good idea! But I suppose this information is useful mainly for advanced users, since the sheet page is most probably hidden (a technical page)

I didn’t change the naming. It was called “Page reference” before, and the reason is because we decided some time ago to use “Page” instead of “Document” in the UI. I agree that for a developer / technical user that knows about the difference between page and document reference this can be confusing, but if we display “Document reference” we may confuse the simple user instead. I know, you’ll argue that this information is for advanced users, but the reality is that we still have macros that require a document reference (and the parameter pretty name might be “Page reference”). I’m not completely against changing this, but I don’t see a perfect solution.

Thanks,
Marius

So +1 from me globally.

I have only 3 comments at this stage:

  • It’s harder to create hidden pages since you need to do it in 2 steps (inline edit + change the visibility afterwards). This means that during some lapse of time the page is not hidden and can be seen in the UI or in search for users not seeing hidden pages.
  • More generally it means more revisions for pages since we used to be able to set the syntax, change the hidden flag, create the content in one go before. Yes, you’re going to say that the wiki edit mode (and even the WYISWYG edit mode - but that could be only temporary) are still there but still. I think the proposal for the Information tab is good. What I’m less sure is whether we also need a way in the inline edit UI to be able to set the hidden flag and the syntax. I think I’d prefer that. In some menu (edit toolbar or elsewhere).
  • I think you were very creative for the languages for which there’s no translation with the idea of the broken/wanted link :slight_smile: However I don’t like the visual effect that much. I cannot refrain from thinking that the wiki is broken (ie that it’s a broken link). I’d prefer some different CSS to differentiate it from a broken/wanted link.

Thanks Marius! Good job :slight_smile:

I don’t think @mflorea proposed to get rid of the edit panel. For me this proposal is only related to the extended info tab.

Right. I thought the plan was to reuse the old right panel even in inline editing.

I agree with this one, it does feel weird. Something like a + sign next to the locale name migh be better.

I think you misunderstood. First of all, when you create the page you use the standalone (old) edit mode. There’s no in-place create ATM. There’s only in-place edit. But even after we add in-place create, the Information tab is available at the bottom of the page when you edit in-place so you can edit in-place and change the hidden flag or syntax at the same time. And of course, the same Information tab is available in view mode so you can change the syntax or the hidden flag without going to edit mode.

That’s how field-by-field in-place edit works. You can change one field without submitting everything and more importantly without loading everything. This means you can change the hidden flag quickly without going to edit mode.

I like it very much, obviously, and I find it consistent with the create links (when the target page is missing). I don’t want to introduce a new styling conversion just for this.

Thanks,
Marius

Definitely, but note that simple users that prefer the WYSIWYG editor will have access only to in-place edit from the UI, so they will have to use the Information tab if they want to change the syntax or the hidden page flag.

Actually he is but I know it because we discussed it :slight_smile:

The plan is to drop the current WYISWYG edit mode at some point (or make it optional but not the default, we haven’t discussed the transition yet). By current, I mean the one where when you click edit you got to the edit action with a different vm for the display.

What Marius proposed was not to make the Information tab better. He proposed that simply because we’re going to have to drop the edit panel! :slight_smile: And then he rationalized it and presented it the other way around in his proposal :wink: Which is clever and his rationalization is good and I agree with it. But it all came from the need to remove the Edit Panel for the inline edit mode.

Yes but in all my points, I’m talking about the future because this is a proposal for the future and we need to decide about what we want to have, not something temporary. Or if we do, we still need to decide what we want to have after the temporary period is over.

Ok. So there are 2 choices:

  • In inline edit mode, you create a doc and you click save and then go to the info tab and change the hidden flag. In this case you could get what I mentioned: “This means that during some lapse of time the page is not hidden and can be seen in the UI or in search for users not seeing hidden pages.”.
  • In inline edit mode, you create a doc, and before you click save (ie the doc doesn’t exist yet), you go to the info tab and change the hidden flag, which would create an empty hidden doc (we’ll need to handle the case), and then you click save to change the content (of an existing doc).

So from what I see, it means that if you want to create hidden doc you need to make sure you set hidden before your click save.

Right?

Sure. It was just a remark @mflorea :slight_smile: I’m trying to imagine the consequences and one of them is more revisions but you’re right, that’s a consequence of inline editing in general. Now, we need to decide if that’s a problem or not for us. I see 2 potential issues:

  • We haven’t fixed our scalability issue when there are lots of revisions but we need to fix that anyway.
  • More revisions means harder to navigate through the revisions, and maybe we need a better revision view (right now, it’s hard to find a past revision you’re looking for since you need to iterate manually to view the diff)

I don’t think that that these 2 issues are going to be a problem with inline editing. However, we’ll need to tackle them when we add realtime to the mix because then it becomes a real problem.

It’s already the case in 12.3-SNAPSHOT: simple users that prefer the WYSIWYG editor are editing plain wiki pages in-place by default. That’s why I need to close this proposal before 12.3 final.

Right.

Yes, but this deserves a separate discussion, probably in the context of adding in-place edit for structured pages (we’re not there yet). For the current proposal, the document properties that will be editable from the Information tab (syntax, hidden flag, original locale) are rarely changed. You won’t see that many revisions because the user changes the syntax, or the hidden flag. I would be more worried about the Save & Continue and auto save creating lots of revisions. But sure, the topic is valid, just that I wouldn’t find a solution because of the Information tab, since this is not the place that will generate most of the revisions. Editable live table and in-place edit for structured pages will.

Thanks,
Marius

It’s now been implemented.