27 Jun
2011
27 Jun
'11
6:26 p.m.
On 06/27/2011 07:19 PM, Thomas Mortagne wrote:
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.
On Mon, Jun 27, 2011 at 15:13, Sergiu
Dumitriu<sergiu(a)xwiki.com> wrote:
Yes, this makes sense for documents belonging to an application which
still uses document names, such as the blog.
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
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.
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.
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.
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 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.
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. 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.
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'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.
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.
(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.
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
(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.
>
> 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