27 Jun
2011
27 Jun
'11
6:53 p.m.
On Mon, Jun 27, 2011 at 18:26, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On 06/27/2011 07:19 PM, Thomas Mortagne wrote:
Was just saying that being base on an object instead of include is not
really new concept.
On Mon, Jun 27, 2011 at 15:13, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
On 06/27/2011 08:38 AM, Ludovic Dubost wrote:
+1
Hi Marius,
2011/6/24 Marius Dumitru Florea<mariusdumitru.florea(a)xwiki.com>
> Hi guys (especially Ludovic and Thibaut),
>
> I read [1] and [2] and I have a few questions. I would like to know very
> clear what UI/UX platform changes are you proposing independent of the
> Application Within Minutes.
I think we need to make it clear that this affects only to applications
and documents created by applications, not to the default way documents
are handled in XWiki. > (A) Page creation
>
> 1. Unique page name
>
> Currently if you specify the name of an existing page in the default
> create page form you get an error message saying that the specified page
> already exists. Do you propose any change to this? Should we instead
> create a page with a similar name based on a specified strategy (e.g.
> MyPage1, MyPage2, with a simple counter strategy).
>
Yes we have a getUniquePageName function but it needs to be improved
Yes, this makes sense for documents belonging to an application which
still uses document names, such as the blog.
> 2. Skip page name
>
> Do you propose to remove the page name field from the default create
> page form (triggered from the Add> Page menu) and to automatically
> generate it from the title (using the default naming strategy)?
>
Yes the idea is to be able to get directly to the form will all the
information to fill.
Create in one less step.
I don't agree that this should affect all "create a new document" forms,
for example when creating a new simple document in the Main space. But
for spaces dedicated to an application, such as the Holiday Request, I'd
be OK with skipping the document name and instead generating one
automatically.
But I still think that not all types of applications must follow this
behavior, since the document name and how it appears in the URL is
important. One of the good points of XWiki (that I like very much) is
semantic URLs, where one can see what a document is about. If we move to
meaningless URLs like /xwiki/Blog/X18733198 then I'd be sad :'(
This said, the application wizard should have a setting for this:
[ ] Generate unique names automatically using this pattern:
[%u-%i__________________________]
[Hint] Any free text entered will be used as-is. The following tokens
can be used:
%a - current user's username
%d - current date, in the yyyyMMdd format
%i - unique counter
%t - current time, in the HHmm format
%u - current user's full name
>
> 3. Implicit location
>
> Do you propose to remove the wiki/space fields from the default create
> page form and instead always create the page in the current wiki/space?
> i.e. Add> Page menu will add the page to the current wiki/space.
>
>
Well I've not thought about this from using the "Add" button, but more
when
we are using the application itself.
The Application has an Add button itself, from this button the space should
be implicit.
So the request would be to be able to pass a parameter to the Add action to
make the space implicit.
Also we could include the "Space" selection in the screen that shows the
full create form, removing the space selection step.
It would be confusing to have the big Add button in the menu do
something different than the big Add button in the application homepage.
It would also be bad UX to have the Add button only on the application
homepage, forcing users to perform an extra step: go to the app homepage
to click Add.
So, the Add menu should have two distinct entries for adding documents:
Add
- Space
---
- Holiday Request [this is the name of the current application]
- Wiki document
- Document from Office
---
- comment, attachment, etc.
I think that using a friendly name, like "Event", "Holiday Request",
"Meeting" is a big usability boost.
If there's no application in the current space, then only the "Wiki
document" entry is displayed.
> 4. Implicit template
>
> Currently template providers can be limited to a list of spaces. Do you
> propose to automatically use a template provider if it is the only one
> defined for the current/selected space?
>
> Same thing. I've not thought about this as used from the "Add" button,
but
from a button in the content area.
We should be able to go directly to the create form for a specific class
which uses a specific template.
See above for a reasoning.
For the implementation, it's not enough to say "if it is the only one
defined for the current/selected space", since templates can target all
the wiki as well. A different approach would be "if a template and only
one targets explicitly the current space".
Another approach would be to somehow mark the space as a space destined
to the XYZ application. This would allow applications to be used in
several spaces. But I'm not sure if this is needed for the scope of this
project, which is to create simple applications.
> 5. Create sheet/template
>
> Are you proposing to have a (slightly) different form even for plain
> wiki pages? e.g. replace the "Save& Continue" and "Save"
buttons with a
> "Create" button. What other differences do you propose?
>
I'm not sure if we need "create". Maybe we can use "save". The
only issue
here is that you won't have the page name at this point.
> -----
>
> I talked with Caty about this and she is against 3. and 4. She would
> improve the current create page form by:
>
> * displaying all the templates independent of the current space
> (currently we display only the templates that can be applied to the
> current space although we can create the page in a different space)
> * when a template is selected, limit the list of spaces from the space
> selector so that the user can choose only a space where the selected
> template can be applied.
I think the list of templates was supposed to be updated depending on
the space selected; isn't it like this right now?
You're proposing to reverse the order: first select the template, then
the space. I agree, this is better, since the user knows what kind of
thing he wants to create more than where the thing should be.
But this means that the user might be surprised if the new document
isn't created in the current space, where he was located initially.
I don't yet agree that the Add menu should list all the templates, even
if they don't apply to the current space. This will make things
complicated if lots of targeted templates are used. They should be
listed on the advanced create form. It's true that the fact that the Add
menu changes its contents is confusing, so I'm not 100% against listing
all the templates, I'd like to see real user feedback about this.
I'm open for discussion on this. In the App
Within Minutes project this is
a bit less important to me.
For me, in the AppWithinMinutes screen where the livetable is listing pages,
it should be possible to go directly to create in one click from there
That's the main priority to me. The behavior of the general Add button is
less important to me.
Maybe what we could imagine if we want to ONLY use this ADD button is to be
able to specify a "default" action for the Add button which is proposed
first to the user and still give him the possibility to propose an alternate
action.
I'm a bit against the ADD button to propose all templates and then propose
the Space. This reduce the contextuality of the Add button. I don't think
it's good especially for non experienced users which could be confused by
all the possibilities.
>
> (B) Display Resolution
>
> (1) Remove the "inline" editing mechanism
>
> What do you propose to do with the "Edit> Inline form" menu seen by
the
> advanced users? Should we keep it and just replace the URL? What about
> simple users, will they be noticing any difference (since we already
> have just one Edit button that points to the proper edit mode)?
>
We won't need the inline mode anymore once we switch to the new method.
What we might need is a way to choose an "ALTERNATE" view or edit mode which
would propose a list of available views or edits.
I don't think we need that for now.
We still need to keep the inline mode as deprecated.
While this wasn't the problem, I'd like to get rid of the special
/inline/ action and replace it with /edit/ and the ?editor=inline URL
parameter, for consistency.
The internals should be the same, though, with the different editors
generated by the different .vm files, keeping the option for advanced
users to choose a different editor.
What changes is the way inline mode is detected. Instead of looking for
an {{include}}, look at the attached objects. Isn't this already the case with the new
EditModeClass ?
EditModeClass is too limited. We need a generic way to specify the sheet
for any action, not just edit.
Thanks,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
>
> (2) Sheet parameters
>
> Do you mean velocity variables defined in the sheet code? This will work
> only if the variables are used after the sheet code is evaluated.
>
No what I mean about parameters is settings that would be stored in the
Sheet (in the XWiki.SheetClass probably) that would give use some rules on
how to display certain things.
For example which tabs to display, wether to display the standard wiki or
wysiwyg editor in the edit screen. This would also be keeping this or that
option from the editors, which buttons to show for saving.
Think that we want to CONTROL as much as we can from what is displayed to
the user without having to HACK the skin. Think that you need to be able to
at least have the way the "inline" mode currently displays (so that the user
does not necessarly feel he is in a special edit mode). In the "inline" mode
we started pretty empty so most of the work was done by the developer.
> (3) Display Resolution Rules
>
> I could find fields for specifying display sheets (defaultViewSheet and
> defaultEditSheet) only in BaseClass (old core). XWikiDocument doesn't
> have any. This makes sense because sheets are in fact *class* sheets.
> That is, you write a sheet for a specific class, you don't write it for
> a specific document. Have I understood correctly that you want to be
> able to create a sheet for a document (not a class)? This could be
> useful for documents that have multiple objects and you need a sheet
> that displays data from all the objects (using the class sheet of one of
> the object types is not enough).
>
Yes we could need to write a view or edit sheet for a documents either with
multiple classes but also a sheet for a class but that would be used for
only ONE specific document.
So it's more about "selecting" the sheet for a specific document (as
opposed
to selecting it for all documents using a class), than to make different
types of sheets for more complex cases.
But we could even have a sheet for a standard wiki document, which could
include plenty of options on how to display the edit form or on which tabs
to display at the bottom of the page.
I think this is a bit too complex for the current phase and goals.
AppWithinMinutes can progress enough before we find the need for custom
document sheets.
>
> Thanks,
> Marius
>
> [1]
>
> http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesPageCrea…
> [2]
>
>
http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutesCoreChan…
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs