7 Jun
2016
7 Jun
'16
5:30 p.m.
On Tue, Jun 7, 2016 at 5:13 PM, Anca Luca <lucaa(a)xwiki.com> wrote:
Hello all,
On Mon, Jun 6, 2016 at 6:31 PM, Ecaterina Moraru (Valica) <
valicac(a)gmail.com> wrote:
<thinking out loud>
Actually, the more I think, the more I realise that applications is a
delicate subject and that it really depends on the application.
Currently we have lots (if not all) of the applications which completely
abstract the concept of page, so the concept of location of that page in
the tree is not something that the user should bother about or even be
aware of. This is currently how we handle most of the applications. We say
that the meeting application creates "entries" or "meetings" but not
"pages", that the calendar app creates "events". Same, blog
application
creates "blog posts". In none of these cases we don't say that those things
are pages and that, just like any other page, they are/can be placed in the
tree along with the other pages of the wiki.
There are applications for which it's easy to introduce the concept of
"location of a page" because it's easy to see the productions of that
application as "pages" that need to be placed in the wiki tree (e.g. blog,
meeting or events are in this case) but there are applications for which
it's not that easy: e.g. file manager application, should one be able to
decide where they create a folder or a file ? wouldn't it be confusing to
have a folder that is, at the same time, a subfolder of another folder and
the child page of another page? Same for the forum application:sShould the
user creating topics in a forum be aware that they are pages so that they
can choose their location in the wiki? In addition, both of these
applications already have a hierarchical structure defined on top of the
general wiki tree, and I'm afraid that giving the user the control on that
could be confusing (and maybe add bugs? - If I'm not wrong, both forum and
filemanager are relying / are planning to rely on the wiki pages tree to
handle rights on their hierarchies).
</thinking out loud>
Thanks,
Anca
Hi,
The Template Provider allows setting the locations where the template must
be available.
Some applications need/encourage their pages to be located in a particular
app location.
Currently, if we set such a location for a template, the template will be
listed in the "Create Page" step only if the user navigates to that
location and clicks on the "Add" button.
One behavior could be that all templates are displayed each time the user
clicks on 'Add', regardless of the initial location.
This would mean splitting the current Location functionality into
"Template
Visibility" and "Creation location restrictions":
- Ideally "Template Visibility" should not be restricted, but we would
need
to keep this field in order to be backward compatible with the current
behavior.
- "Creation location restrictions" would indicate if the page needs to be
created in a particular location. The user will not be allowed to create
somewhere else and be warned by an error message.
I would identify 3 things that a template provider should be able to do:
* be visible only in certain locations (the current feature, but maybe a
bit more sophisticated)
* recommend a location for the pages created from that template -
"recommend" here would mean that the user could change that location if
they wanted
* restrict a location for the pages created from that template -
"restrict" would mean that the location would be chosen by the template
provider and the user would not be able to change it
Note that the 3 above don't exclude eachother, so we can have them all
implemented as options of the template provider.
I think that the template provider should be able to fully control them.
I.e. the template provider should decide if the location is to be
restricted or only recommended. In addition, I see usecases for all 3 of
them, so I don't think we should completely exclude one from the picture.
Now, in my opinion, the rest is about how we present these options in the
creation screen (do we present them all as equally important?) and what do
we implement for the default applications. See my answers to your questions
below.
This mail's purpose is to debate:
A. If templates should be visible everywhere or just in a particular
location?
As I said, we should allow the template provider to decide that, as we
currently do.
B. Should we recommend applications to restrict
the creation of pages to a
particular location?
I think this depends on the application, on what kind of data it
stores, how it handles rights, etc.
Now, for a general recommendation, I think it would not be efficient to
recommend restriction. I think at most we could guide towards a
"recommended" location for the pages (in the sense described above), but it
really depends on each application. There is great value in being able to
create application pages anywhere on your wiki, so we shouldn't recommend
against.
HOWEVER
My biggest concern here is that the users could very easily get confused
between the application concept and the application page concept. For
example, assume we'd have a blog post template provider available
everywhere on the wiki, without a recommended location. I fear that the
users will not realize that choosing the "Blog Post" template provider in
the create page screen is not equivalent with creating a blog post using
the create blog post form on the homepage of the blog application (the page
accessible when clicking on the blog application). Same for all the app
within minutes: "Create new entry" on the homepage of the application will
create a new entry of the application "contained" in the application (read
"in the data subtree of the application"), while choosing the template of
that application from a create screen will not have the same effect. I can
easily see the users getting a little confused with these.
I think we can have solutions to this confusion that are only reelated to
presentation, not to technical stuff, so it should not be scary.
Thanks,
Anca
Let me know what you think.
Thanks,
Caty
Related:
[1] http://jira.xwiki.org/browse/XWIKI-8759
[2]
http://design.xwiki.org/xwiki/bin/view/Proposal/HomepageSketches/HomepageTe…
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs