On 05/13/2011 01:25 PM, Guillaume Lerouge wrote: +1 Thanks, Marius

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 <ludovic(a)xwiki.com> wrote:

Hi, On Wed, May 25, 2011 at 2:01 PM, Ecaterina Moraru (Valica) < valicac(a)gmail.com&gt; wrote: 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. 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. 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. 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 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. If we remove one that would be the admin message, but I still think both make sense. 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. 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? 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

Hi, On Mon, Jun 6, 2011 at 10:14, Thibaut Camberlin &lt;thibaut.camberlin(a)xwiki.com > Hi, > > On Wed, May 25, 2011 at 2:01 PM, Ecaterina Moraru (Valica) < > valicac(a)gmail.com> > > On Wed, May 18, 2011 at 22:45, Thibaut Camberlin < > > thibaut.camberlin(a)xwiki.com> > > > > 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 &lt;ludovic(a)xwiki.com&gt; > > > > > > > > > > > > > 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) > > > >>> &lt;valicac(a)gmail.com&gt;wrote;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/ApplicationWithinM… > > > >>>> > > > >>>> 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 > > > >>>> devs(a)xwiki.org > > > >>>> http://lists.xwiki.org/mailman/listinfo/devs > > > >>>> > > > >>> _______________________________________________ > > > >>> devs mailing list > > > >>> devs(a)xwiki.org > > > >>> http://lists.xwiki.org/mailman/listinfo/devs > > > >>> > > > >> _______________________________________________ > > > >> devs mailing list > > > >> devs(a)xwiki.org > > > >> 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 > > > > devs(a)xwiki.org > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > _______________________________________________ > > > devs mailing list > > > devs(a)xwiki.org > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

On Mon, May 16, 2011 at 12:21, Oana Tabaranu &lt;oana.tabaranu(a)xwiki.com&gt;wrote;wrote: Thanks Oana, could do. Caty