On 05/13/2011 01:25 PM, Guillaume Lerouge wrote:

Hi Caty,

amazing work, this looks very very cool!!

+1 Thanks, Marius

As an added bonus plenty of the components you're using in the mockups are already there or mostly there, which will probably make this easier to build.

I'm really looking forward to seeing this brought to life, I think it wil really show the added-value of XWiki to end-users :-)

Guillaume

On Fri, May 13, 2011 at 12:08, Ecaterina Moraru (Valica) <[email protected]>wrote:

...

Hi,

According to the feedback received I've made another proposal for the Application Within Minutes

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMi...

Changes: - Wizard style creation - Structure in a form editor style (drag&drop, refresh preview on change)

Remarks: - "Create application" could be part of the action menu's "Add" submenu and act as a wizard for the creation process. As a result we will have a space for each application that will list on it's homepage the entries livetable. The structure will be changed by entering again the wizard.

Thanks, Caty

References: [Proposal][UX] Application Within Minutes - Proposal 1: http://xwiki.markmail.org/thread/tvxnoabhbwfcpwmk _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, The proposal is great. Users will love it. Here are my comments: - Details step - I think we should add Application key field. For example, we can have application name "List of our events" that would not fit as a key / URL pattern. In this example a proper key could be "EVT". - Structure step - Lists: I think we should merge "Dropdown", "Check Box" and "Radio button" into a "List of items" in the right panel in the "Standard" inputs section, since "Dropdown", "Check Box" and "Radio button" are the display type of list the user will want to have - I think "Advanced" section (right panel) should also be moved to the advanced configuration of the above "List of items". See what I mean here, at Advanced List section : http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AWMListManagement - Presentation - We need "Welcome message". That will be the first thing displayed when people visit the application. I think that a "Welcome Message" (user oriented) is different from the "Application Description" (for other admins). - In "Entries livetable fields" the list of all possible fields is not displayed. That forces the user to remember or click "Previous step". We could have a two column table. The left one would be "Available fields", the right one "Displayed fields". A field could only be in one column. - Other - On slide 15, I can read "Add new entry" with an input for the report name. We should just have an "Add" button. App within minute will free the user from setting a page name (using the application key set at step 1) - We are missing the administration section that will enable the user to administer a simple list: add, remove and update list items. See http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AWMListManagement(a link to it could be added after "Application wizard", slide 15) - I noticed on slide 10, 11 and 12 that list administration seems to be inside the wizard. My concern is that: 1. It does not seem scalable 2. Forcing the user to go through step one, then look for the list he is looking for (only simple lists need that admin) seems like a painful process. At some point we should also do a review of the terms used. For example I am not sure "Label" for properties name is the best word. "Name" would make more sense IMO. Thanks -- Thibaut On Tue, May 17, 2011 at 10:42 AM, Ludovic Dubost <[email protected]> wrote:

The proposal is indeed great. The only comments I have on this proposal are:

- that there should be some entry points for "Advanced modes" -> access to the standard detailed class editor -> access to all pages comprising the application (sheet, templates, etc..) in a IDE-similar mode - an export feature to export the application with or without the data comprising the application (this export feature would have XAR but also would be linked to the Extension Manager to publish the application to be installable through the Extension Manager)

In any case, this proposal is sufficiently ready from my POV to start implementation. The main task now is to find people to work on it.

Great work Cati.

Ludovic

Le 16/05/11 21:03, Marius Dumitru Florea a écrit :

On 05/13/2011 01:25 PM, Guillaume Lerouge wrote:

...

...

Hi Caty,

amazing work, this looks very very cool!!

+1

Thanks, Marius

As an added bonus plenty of the components you're using in the mockups

...

are already there or mostly there, which will probably make this easier to build.

I'm really looking forward to seeing this brought to life, I think it wil really show the added-value of XWiki to end-users :-)

Guillaume

On Fri, May 13, 2011 at 12:08, Ecaterina Moraru (Valica) <[email protected]>wrote:

Hi,

...

According to the feedback received I've made another proposal for the Application Within Minutes

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMi...

Changes: - Wizard style creation - Structure in a form editor style (drag&drop, refresh preview on change)

Remarks: - "Create application" could be part of the action menu's "Add" submenu and act as a wizard for the creation process. As a result we will have a space for each application that will list on it's homepage the entries livetable. The structure will be changed by entering again the wizard.

Thanks, Caty

References: [Proposal][UX] Application Within Minutes - Proposal 1: http://xwiki.markmail.org/thread/tvxnoabhbwfcpwmk _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, On Wed, May 25, 2011 at 2:01 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

On Wed, May 18, 2011 at 22:45, Thibaut Camberlin < [email protected]> wrote:

...

Hi,

The proposal is great. Users will love it.

Here are my comments:

- Details step - I think we should add Application key field. For example, we can have application name "List of our events" that would not fit as a key / URL pattern. In this example a proper key could be "EVT".

IMO this is the same discussion as page name vb page title. If we are gonna make this wizard for end -users than don't bother them with technical issues. Auto generate the key and don't ask for something that doesn't concern the user or brings value to him.

As a user, when I create a project on Jira, I am happy to be able to set the project key. I do not consider it technical but something that will help find find the items I am looking for. What would be the algorithm that you propose for the auto-generated pattern? First letter of each word? In my example that would be LOOE. Makes sense. I propose that we automatically generate that key when creating the application, but changeable (similar behaviour to when creating a user when we automatically concatenate First Name and Last Name for the login name). I am +1 for that.

...

- Structure step - Lists: I think we should merge "Dropdown", "Check Box" and "Radio button" into a "List of items" in the right panel in the "Standard" inputs section, since "Dropdown", "Check Box" and "Radio button" are the display type of list the user will want to have

We could do that but we could also leave them separate. The nice thing about having them separate is the icon they have. That icon also provide hints about the visualization of the list in the final step (without the need to drag them and preview the modes). Having just the text 'Check Box', 'Radio button' may not mean anything to some users.

About the icons, they are not present in my mockups, true. We could add them, and update label "Radio Box" to "Simple select", "Check box" to "Multiple select" as I agree it is not meaningful for a user. The concern I have making "Check Box", "Radio Box" etc. seperate is when I want to update my application. Imagine I have set up my new application, I even used it to create some entries. I realize that for one of the proporties, say "Sponsor" one, I don't want a single select anymore (radio box) but multiple one (check box): * In the option where "Radio box", "Check box" are merged, the user selects "Multiple select" instead of "Single select" and he is good to go. * In the option where "Radio box", "Check box" are seperate, you would have to remove that property, add a new one, reconfigure the title, the possible options, etc. Moreover, nothing ensures the user that all the values previously entered will not be thrown away. Worse than that, if property name is generated based on property pretty name (there is a good chance that it will be the case) and the user does not input the exact same name (typo for example) then all this property WILL be thrown away.

...

- I think "Advanced" section (right panel) should also be moved to

the

...

advanced configuration of the above "List of items". See what I mean here, at Advanced List section :

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AWMListManagement

...

We usually compact things when we want to save space. This is not necessarily the case. Compacting increase the complexity of things and make them harder to discover.

IMO something is hard to discover when it is put in a section you don't expect it to be. When I want to add a property of type list, I will first go to "List of items" and not to advanced section. First beause I want a list, second because at the moment I add my property, I may not know yet that it will be an advanced one (same update issue mentioned above applies here) Here the purpose is not to compact things, it is to logically group them, hiding what is not needed first. For example all options of "Advanced List" from my mockups should be hidden until the user clicks on "Advanced List" radio button.

...

- Presentation - We need "Welcome message". That will be the first thing displayed when people visit the application. I think that a "Welcome Message" (user oriented) is different from the "Application Description" (for other admins).

IMO they are the same thing. Why would we need such a separation? Why would admins not understand what this application is about from the user description and vice-versa?

Example of application description message (for admins): We use that app to manage events proposals made by our employees. Intially managed using an excel file, you can find more information on its versions and evolutions on <this page>. Example of application welcome message (for users): Welcome to our events proposal page! Make sure that our company would be ok to organize the event you suggest. If you are unsure, please call Brian: 555-0123

Where would the admin message be displayed (compared to the user's one)?

Admin message would stay in the application (or be displayed on the table listing all applications) Welcome message would be displayed on the homepage of the application, above the livetable listing application entries.

Also I think these questions will be in the user's mind. Why does an application ask me to provide a welcome message that I will not be able to view (this is the case if application can be created also by users). I think some users will put the same message twice or with very little modifications, so I don't agree in having such a separation.

If we remove one that would be the admin message, but I still think both make sense.

...

- In "Entries livetable fields" the list of all possible fields is

not

...

displayed. That forces the user to remember or click "Previous

step".

...

We could have a two column table. The left one would be "Available fields", the right one "Displayed fields". A field could only be in one column.

This solution is not very extensible and takes a lot of space. IMO the adding step is done though auto-complete. When you enter the field we should have the available fields named there.

It much easier to read all available properties and decide whether you want them on the homepage (check) or not, rather than having to remember how you named properties that you want display on the home page. Moreover, several columns with many entries is what we have (and will with the new version if I am not mistaking) with multipage export application, and it works well.

...

- Other - On slide 15, I can read "Add new entry" with an input for the report name. We should just have an "Add" button. App within minute will free the user from setting a page name (using the application key set at step 1)

This also need to be discussed from an implementation point of view with the other developers. IMO when looking at the livetable on slide 15 I like it very much that I can have titles like 'Report 1', 'Week 14 Report', etc. and I would prefer this use case any time instead of having 'Report02302012', 'Report23523582'.

Entry title is not the same as entry key. Entry title is a property that the user will be able to add when creating his application using the wizard. In some applications, we will have a title, in others we will not. The user will then be able to decide whether he wants a property to be listed in the livetable of the home page or not. Why would title entry be a mandatory property more than any other property?

The entry title is an important thing and summaries all the entry content. Also is in the style of all the other wiki pages and I would like to keep it. This is also something we need to agree on.

Yes, that is something that needs to be discussed at the wiki page level, I agree. See http://xwiki.markmail.org/thread/oaue6zys2bvpnbz5 and XE-907. With application within minutes, the implementation needs to be discussed by developers, I agree. But since title is a property just like first name or date of birth are, I don't see why the presence of this property for all entries of all applications would need to be discussed. IMO we should consider title just like any other property. Thanks, Thibaut

...

- We are missing the administration section that will enable the

user

...

to administer a simple list: add, remove and update list items. See

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AWMListManagement(a

...

link to it could be added after "Application wizard", slide 15)

In the settings I re-added the Wizard step. When I thought about this I thought about a very beginner user that would be more comfortable of using the same creation wizard to modify stuff instead of having 2 or 3 different sections to administrate his application.

...

- I noticed on slide 10, 11 and 12 that list administration seems to be inside the wizard. My concern is that: 1. It does not seem scalable 2. Forcing the user to go through step one, then look for the

list

...

he is looking for (only simple lists need that admin) seems like a painful process.

I'm not user I understand what list administration means.

...

At some point we should also do a review of the terms used. For example I am not sure "Label" for properties name is the best word. "Name" would make more sense IMO.

Sure.

Thanks, Caty

...

Thanks -- Thibaut

On Tue, May 17, 2011 at 10:42 AM, Ludovic Dubost <[email protected]> wrote:

...

The proposal is indeed great. The only comments I have on this proposal are:

- that there should be some entry points for "Advanced modes" -> access to the standard detailed class editor -> access to all pages comprising the application (sheet, templates, etc..) in a IDE-similar mode - an export feature to export the application with or without the data comprising the application (this export feature would have XAR but also would be linked to the Extension Manager to publish the application to be installable through

the

...

Extension Manager)

In any case, this proposal is sufficiently ready from my POV to start implementation. The main task now is to find people to work on it.

Great work Cati.

Ludovic

Le 16/05/11 21:03, Marius Dumitru Florea a écrit :

On 05/13/2011 01:25 PM, Guillaume Lerouge wrote:

...

...

Hi Caty,

amazing work, this looks very very cool!!

+1

Thanks, Marius

As an added bonus plenty of the components you're using in the

mockups

...

...

are already there or mostly there, which will probably make this easier to build.

I'm really looking forward to seeing this brought to life, I think it wil really show the added-value of XWiki to end-users :-)

Guillaume

On Fri, May 13, 2011 at 12:08, Ecaterina Moraru (Valica) <[email protected]>wrote:

Hi,

...

According to the feedback received I've made another proposal for

the

...

Application Within Minutes

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMi...

...

...

...

...

...

Changes: - Wizard style creation - Structure in a form editor style (drag&drop, refresh preview on change)

Remarks: - "Create application" could be part of the action menu's "Add"

submenu

...

and act as a wizard for the creation process. As a result we will have a space for each application that will list on it's homepage the entries livetable. The structure will be changed by entering again the wizard.

Thanks, Caty

References: [Proposal][UX] Application Within Minutes - Proposal 1: http://xwiki.markmail.org/thread/tvxnoabhbwfcpwmk _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hi, On Mon, Jun 6, 2011 at 10:14, Thibaut Camberlin <[email protected]

wrote:

Hi,

On Wed, May 25, 2011 at 2:01 PM, Ecaterina Moraru (Valica) < [email protected]> wrote:

...

On Wed, May 18, 2011 at 22:45, Thibaut Camberlin < [email protected]> wrote:

...

Hi,

The proposal is great. Users will love it.

Here are my comments:

- Details step - I think we should add Application key field. For example, we can have application name "List of our events" that would not fit as a key / URL pattern. In this example a proper key could be "EVT".

IMO this is the same discussion as page name vb page title. If we are gonna make this wizard for end -users than don't bother them with technical issues. Auto generate the key and don't ask for something that doesn't concern the user or brings value to him.

As a user, when I create a project on Jira, I am happy to be able to set the project key. I do not consider it technical but something that will help find find the items I am looking for. What would be the algorithm that you propose for the auto-generated pattern? First letter of each word? In my example that would be LOOE. Makes sense. I propose that we automatically generate that key when creating the application, but changeable (similar behaviour to when creating a user when we automatically concatenate First Name and Last Name for the login name). I am +1 for that.

...

...

- Structure step - Lists: I think we should merge "Dropdown", "Check Box" and "Radio button" into a "List of items" in the right panel in the "Standard" inputs section, since "Dropdown", "Check Box" and "Radio button" are the display type of list the user will want to have

We could do that but we could also leave them separate. The nice thing about having them separate is the icon they have. That icon also provide hints about the visualization of the list in the final step (without the need

to

...

drag them and preview the modes). Having just the text 'Check Box', 'Radio button' may not mean anything to some users.

About the icons, they are not present in my mockups, true. We could add them, and update label "Radio Box" to "Simple select", "Check box" to "Multiple select" as I agree it is not meaningful for a user.

The concern I have making "Check Box", "Radio Box" etc. seperate is when I want to update my application. Imagine I have set up my new application, I even used it to create some entries. I realize that for one of the proporties, say "Sponsor" one, I don't want a single select anymore (radio box) but multiple one (check box): * In the option where "Radio box", "Check box" are merged, the user selects "Multiple select" instead of "Single select" and he is good to go. * In the option where "Radio box", "Check box" are seperate, you would have to remove that property, add a new one, reconfigure the title, the possible options, etc. Moreover, nothing ensures the user that all the values previously entered will not be thrown away. Worse than that, if property name is generated based on property pretty name (there is a good chance that it will be the case) and the user does not input the exact same name (typo for example) then all this property WILL be thrown away.

...

...

- I think "Advanced" section (right panel) should also be moved to

the

...

advanced configuration of the above "List of items". See what I mean here, at Advanced List section :

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AWMListManagement

...

...

We usually compact things when we want to save space. This is not necessarily the case. Compacting increase the complexity of things and make them harder to discover.

IMO something is hard to discover when it is put in a section you don't expect it to be. When I want to add a property of type list, I will first go to "List of items" and not to advanced section. First beause I want a list, second because at the moment I add my property, I may not know yet that it will be an advanced one (same update issue mentioned above applies here)

Here the purpose is not to compact things, it is to logically group them, hiding what is not needed first. For example all options of "Advanced List" from my mockups should be hidden until the user clicks on "Advanced List" radio button.

...

...

- Presentation - We need "Welcome message". That will be the first thing

displayed

...

...

when people visit the application. I think that a "Welcome

Message"

...

(user oriented) is different from the "Application Description" (for other admins).

IMO they are the same thing. Why would we need such a separation? Why would admins not understand what this application is about from the user description and vice-versa?

Example of application description message (for admins): We use that app to manage events proposals made by our employees. Intially managed using an excel file, you can find more information on its versions and evolutions on <this page>.

Example of application welcome message (for users): Welcome to our events proposal page! Make sure that our company would be ok to organize the event you suggest. If you are unsure, please call Brian: 555-0123

...

Where would the admin message be displayed (compared to the user's one)?

Admin message would stay in the application (or be displayed on the table listing all applications)

Welcome message would be displayed on the homepage of the application, above the livetable listing application entries.

...

Also I think these questions will be in the user's mind. Why does an application ask me to provide a welcome message that I will not be able to view (this is the case if application can be created also by users). I think some users will put the same message twice or with very little modifications, so I don't agree in having such a separation.

If we remove one that would be the admin message, but I still think both make sense.

...

...

- In "Entries livetable fields" the list of all possible fields is

not

...

displayed. That forces the user to remember or click "Previous

step".

...

We could have a two column table. The left one would be "Available fields", the right one "Displayed fields". A field could only be in one column.

This solution is not very extensible and takes a lot of space. IMO the adding step is done though auto-complete. When you enter the field we should have the available fields named there.

It much easier to read all available properties and decide whether you want them on the homepage (check) or not, rather than having to remember how you named properties that you want display on the home page. Moreover, several columns with many entries is what we have (and will with the new version if I am not mistaking) with multipage export application, and it works well.

...

...

- Other - On slide 15, I can read "Add new entry" with an input for the

report

...

...

name. We should just have an "Add" button. App within minute will free the user from setting a page name (using the application key set at

step

...

1)

This also need to be discussed from an implementation point of view with the other developers. IMO when looking at the livetable on slide 15 I like it very much that I can have titles like 'Report 1', 'Week 14 Report', etc. and I would prefer this use case any time instead of having 'Report02302012', 'Report23523582'.

Entry title is not the same as entry key. Entry title is a property that the user will be able to add when creating his application using the wizard. In some applications, we will have a title, in others we will not. The user will then be able to decide whether he wants a property to be listed in the livetable of the home page or not. Why would title entry be a mandatory property more than any other property?

...

The entry title is an important thing and summaries all the entry content. Also is in the style of all the other wiki pages and I would like to keep it. This is also something we need to agree on.

Yes, that is something that needs to be discussed at the wiki page level, I agree. See http://xwiki.markmail.org/thread/oaue6zys2bvpnbz5 and XE-907.

With application within minutes, the implementation needs to be discussed by developers, I agree. But since title is a property just like first name or date of birth are, I don't see why the presence of this property for all entries of all applications would need to be discussed. IMO we should consider title just like any other property.

And sometimes you want the title to be set dynamically based on the value of some properties. For instance for a profile page, you might want the displayed title of the page to be a combination of the values of the first name and last name of the person, that are 2 distinct fields in the template. However you still need to be able to display something as the title of the page in the interface of the wiki. Right now if no title is set, it defaults to the page name, which would be the application key followed by a number in this case -> it's not very nice. So we might want to force the user to say which field should be used as a title. Guillaume Thanks,

Thibaut

...

...

- We are missing the administration section that will enable the

user

...

to administer a simple list: add, remove and update list items.

See

...

...

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/AWMListManagement(a

...

...

link to it could be added after "Application wizard", slide 15)

In the settings I re-added the Wizard step. When I thought about this I thought about a very beginner user that would be more comfortable of using the same creation wizard to modify stuff instead of having 2 or 3 different sections to administrate his application.

...

- I noticed on slide 10, 11 and 12 that list administration seems

to

...

be inside the wizard. My concern is that: 1. It does not seem scalable 2. Forcing the user to go through step one, then look for the

list

...

he is looking for (only simple lists need that admin) seems like a painful process.

I'm not user I understand what list administration means.

...

...

At some point we should also do a review of the terms used. For example

I

...

...

am not sure "Label" for properties name is the best word. "Name" would make more sense IMO.

Sure.

Thanks, Caty

...

Thanks -- Thibaut

On Tue, May 17, 2011 at 10:42 AM, Ludovic Dubost <[email protected]> wrote:

...

The proposal is indeed great. The only comments I have on this

proposal

...

are:

- that there should be some entry points for "Advanced modes" -> access to the standard detailed class editor -> access to all pages comprising the application (sheet, templates, etc..) in a IDE-similar mode - an export feature to export the application with or without the data comprising the application (this export feature would have XAR but also would be linked to the Extension Manager to publish the application to be installable through the Extension Manager)

In any case, this proposal is sufficiently ready from my POV to start implementation. The main task now is to find people to work on it.

Great work Cati.

Ludovic

Le 16/05/11 21:03, Marius Dumitru Florea a écrit :

On 05/13/2011 01:25 PM, Guillaume Lerouge wrote:

...

...

Hi Caty,

amazing work, this looks very very cool!!

+1

Thanks, Marius

As an added bonus plenty of the components you're using in the

mockups

...

...

are already there or mostly there, which will probably make this easier to build.

I'm really looking forward to seeing this brought to life, I think it wil really show the added-value of XWiki to end-users :-)

Guillaume

On Fri, May 13, 2011 at 12:08, Ecaterina Moraru (Valica) <[email protected]>wrote:

Hi, > > According to the feedback received I've made another proposal for the > Application Within Minutes > > >

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMi...

...

...

...

...

...

> > Changes: > - Wizard style creation > - Structure in a form editor style (drag&drop, refresh preview on > change) > > Remarks: > - "Create application" could be part of the action menu's "Add" submenu > and > act as a wizard for the creation process. > As a result we will have a space for each application that will list on > it's > homepage the entries livetable. > The structure will be changed by entering again the wizard. > > Thanks, > Caty > > > References: > [Proposal][UX] Application Within Minutes - Proposal 1: > http://xwiki.markmail.org/thread/tvxnoabhbwfcpwmk > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Mon, May 16, 2011 at 12:21, Oana Tabaranu <[email protected]>wrote:

Hi,

The proposal looks very nice and I am looking forward to see it come to life. One improvement I would like to suggest: the "Standard", "Pickers" and "Advanced" categories on /Step 2-Define the structure of your application/ could be collapsible ("Standard" and "Pickers" expanded by default and "Advanced" collapsed by default).

Thanks Oana, could do. Caty

Thx, Oana

On 05/13/2011 01:08 PM, Ecaterina Moraru (Valica) wrote:

...

Hi,

According to the feedback received I've made another proposal for the Application Within Minutes

http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMi...

...

Changes: - Wizard style creation - Structure in a form editor style (drag&drop, refresh preview on change)

Remarks: - "Create application" could be part of the action menu's "Add" submenu

and

...

act as a wizard for the creation process. As a result we will have a space for each application that will list on it's homepage the entries livetable. The structure will be changed by entering again the wizard.

Thanks, Caty

References: [Proposal][UX] Application Within Minutes - Proposal 1: http://xwiki.markmail.org/thread/tvxnoabhbwfcpwmk _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Oana Tabaranu

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs