18 Jun
2015
18 Jun
'15
5:22 p.m.
Hi,
Regarding Anca's comment about:
functionality got deprecated by the ability to filter in the SOLR Search.
I don't see any reason to keep the Attachments tabs (when I can filter for
attachments) - also the current Attachment tabs list attachments even if
the containing page is hidden, so it's clearly we have some deprecated code
there. Same for Deleted Doc and Deleted Attachments which should be
replaced with a Recycle bin; Orphaned Pages.
What should remain is a Documents/Pages Index, with a Livetable and a Tree
display + a Recycle Bin.
current
location, with the ability to change it to other parent (Tree or
Input).
http://xwiki.markmail.org/thread/fz6fonamx4d3x25i) that we might even
replace this macro with the tree, or even remove it in favor of a
Navigation panel.
Also I think now is a good time to clean a bit old stufff and deprecate /
remove it.
I don't see no reason to keep/update the create panel or any other panels
that we haven't used in years. I already mentioned tabs in AllDocs that
have been deprecated by new features. Even the Information tabs is listing
the parent that we will provide additional view for it. Also the Spaces
Macro, why improve it when we have a Document Tree Macro?
For me Option 1 is too complex and this complexity doesn't provide any
benefit for the end-user. All the user wants is to be able to create
hierarchies. He doesn't care if there are spaces or pages.
Thanks,
Caty
* Said differently she believes that the UI should be
in accordance with
the model and that it’s a bit utopian to think that users will never see
it. But she also acknowledges that it could be interesting for some users
or xwiki instances to have a simplified view.
I think it depends on how well we hide something. Sure some users might
find out there is a difference between Comments and Attachments
implementation, even if in the UI they are represented at the same level
(docextra) as entities that can be added on a page. It's our duty to make
things transparent / easier for user, no matter what is the behind
implementation.
---
I already mentioned that I prefer Option 2, creating the UI for Nested
Documents.
This way we remove a level from XWiki's structure complexity and remain
only with 'main wiki / wikis / pages'.
Users will create hierarchies of pages. They will be making
Add/Delete/Move/.../Administer on nodes.
It will be harder for us with this transition from nested spaces to nested
documents to provide some of the magic to make actions invisible for
end-users (like transforming pages into spaces, or creating page
administration, etc.).
With a difference in the UI for Spaces and Pages, for end-users I think it
will be very hard to understand why:
- they can create multiple spaces, but not pages;
- why there are differences between actions that can be performed on spaces
and pages;
- why we have pages, but we don't have WebHome pages on spaces;
- why we have administration of multiple levels of spaces, but we don't
have at page level;
- why are the leaves so important that they are represented in a different
manner;
- why we separate everywhere in the UI the spaces concept, but we don't
quite use it, since spaces need pages in order to exist.
- even spaces.webhomes dashboards might sound a bit off, since users are
mostly interested in content when it comes to such hierarchies.
On Thu, Jun 18, 2015 at 1:33 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
no reason to alter all the UI in order to show the Space concept.
I propose this option maybe would display a full reference of the document
in the #docextra Information tab, in order for the developer to use in
scripting that reference.
So we really need to start deciding what will be
the differences from a
user POV about the “Nested Spaces” view and the “Nested Documents” view.
There are 2 possibilities I can think ok.
Assumptions:
- In both cases we assume that by default XE is in “Nested Documents”
view when you install it and that going to the “Nested Spaces” view is an
advanced and technical option.
- In both cases we implement the hiding of WebHome everywhere in the UI
by assimilating WebHome and the Space it’s in.
Option 1
========
Concept: We clearly show the differences between Spaces and Documents in
the UI
* Have an checkbox option in the user profile that is named something
like “Show the Space concept”
If this option's target are just advanced users / developers, I don't see
* Everywhere in the UI where we display spaces
(and there are lots of
places), we display them differently than documents. Some examples:
** In the Document Tree the icon used to display spaces is different than
the one used to display documents
** In the Index application we would need to either have 2 tabs: one for
Documents and one for Spaces or a single one but in this case the Livetable
column should be named “Document and Spaces” and both entities should be
displayed differently (I’m assuming we want a single column, see T13 at
http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces#HOriginallisto…
)
I would disagree to add more tabs in the AllDocs page. IMO some of the
** The Add button would list 2 actions: Add >
Page and Add > Space
** In the Main Wiki administration UI we have a “Select Space to
Administer” label to choose the space to administer
** In the Add Page UI we ask the user to select both the document name
and the space in which it’s located
** We can keep the “Space List” on the home page’s dashboard
Option 2
========
Concept: We show Spaces and Documents as similarly as possible in the UI
to have the same UI as much as possible between “Nested Spaces” and “Nested
Documents”.
* In the user profile, we would have a checkbox option named something
like “Ability to create several Documents in the same Space”
* Everywhere in the UI we don’t differentiate Spaces and Documents. The
same examples as above would become:
** In the Document Tree we use the same icon (a node icon) to display
either spaces or documents
** In the Index Application, we have a single Document tab and in the
Livetable column is named “Location” (or “Document Names”) and the
reference is displayed but without showing different icons for Spaces or
Documents.
** The Add > Space menu entry could be removed and only an Add > Page
entry would stay but when you click on it, you’d still have the ability to
create new Spaces. Basically we ask the user to select both the document
name and the space in which it’s located
We will have just one Add - Page. It will default the parent to the ** We replace the “Space List” on the home page’s
dashboard by a
“Document List” widget (showing both spaces and pages).
I've mentioned some notes on 'The future of Spaces macro' (
In summary, option 2 reduces the difference between Nested Documents and
Nested Spaces to the Add > Page UI.
Pros/Cons
=========
* Option 1:
** Strong difference between Space/Documents in the UI
** Hard to implement: lots of places need to have different behavior
depending on whether the user profile option is turned on or off
** Existing extensions don’t need to be modified to feel natural if
you’re in the “Nested Spaces” mode. However note that since we want to have
Nested Documents by default these extensions must be updated ASAP anyway to
reflect that.
* Option 2:
** Smaller difference between Space/Document in the UI
** Easy to implement since the only UI
** Existing extensions may not feel natural (until they’re updated for
Nested Documents but we need to do that anyway)
WDYT? I’m worried that Option 1 is going to be costly to develop and
maintain.
Anca, since you were the one who raised this idea of keeping both “Nested
Spaces” and “Nested Documents” in the UI, what’s your POV?
Thanks
-Vincent