On Jan 24, 2013, at 8:42 PM, Denis Gervalle <[email protected]> wrote: > On Tue, Nov 27, 2012 at 7:16 PM, Vincent Massol <[email protected]> wrote: > >> >> On Nov 27, 2012, at 6:59 PM, Eduard Moraru <[email protected]> wrote: >> >>> Hi, >>> >>> I`m with Denis on this one. >>> >>> Besides knowing from which module the sub-module is, you also lose >>> top-module information. Couple that with the fact that we have some >> modules >>> with almost identical names in both platform and commons (due to partial >>> moving to commons of some sub-modules), it will become a bit tricky to >> know >>> which one is actually mentioned. Displaying the extension ID in the EM >>> would help a bit on this aspect. >>> >>> Another inconvenient of pretty names is that they can get messy fast. In >>> lack of a convention, we risk confusing users more than helping them. >>> Besides that, we will be very tempted to name modules by a similar scheme >>> that we have today, due to the hierarchical nature and the "part-whole" >>> relationship between modules. I am not sure on what improvement we will >>> have with this approach (option 2), instead of maybe dropping the "-" >>> characters from the pretty name. >>> >>> Extension search also should work on, since users search for keywords and >>> that's generally what we use right now in the module names. Adding a lot >> of >>> stopwords around those keywords (like Extension Repository *for* Maven) >> is >>> not much of an UX improvement IMO. >>> >>> Do we, by any chance have some reports/complaints from user about the >>> current way of naming extensions? I find the we currently have a decent >>> balance between technical and pretty names. We generally have 3 to 4 >>> components in the module's name and, rarely, in some modules that are not >>> really exposed to the user (corner cases), we might exceed that to 5-6. >> >> What Thomas and I are proposing is exactly that: to keep the current names >> on e.x.o. Now what you propose when you vote +1 for 1) is the opposite, >> i.e. for example instead of having "Blog Application" you'd have "XWiki >> Platform - Blog - UI" (on >> http://extensions.xwiki.org/xwiki/bin/view/Extension/Blog+Application). I >> don't see how worse it could be… :) >> >> The reason we don't have any complaints is exactly because those names are >> good! >> > > Sorry to revive this the hard way, but I have to complaint ! > > When I startup my freshly upgraded 4.4.1 Wiki, DW came in and propose me to > upgrade: > > XWiki Platform - Application Manager - API 4.3.1 (Upgradable) > XWiki Platform - Wiki Manager - UI 4.3.1 (Upgradable) > XWiki Platform - Wiki Manager - API 4.3.1 (Upgradable) > > A optional proposal I have discarded. > In EM, I see, among others, the following installed extensions: > > XWiki Platform - Administration - UI 4.4.1 (Uninstallable) > XWiki Platform - Application Manager - API 4.3.1 (Uninstallable) > XWiki Platform - Wiki Manager - UI 4.3.1 (Uninstallable) > XWiki Platform - Wiki Manager - API 4.3.1 (Uninstallable) > > but into Add Extension, it propose me, among others, the following: > > Administration Application 4.4.1 (Uninstallable) > Application Manager API 4.4.1 (Upgradable) > Application Manager Application 4.2 (Instalable) > Wiki Manager Application 4.4.1 (Upgradable) > > Except if I am an expert in XWiki packages, I cannot understand some of > these are the same extensions, others are not. > This cause IMO a lot of confusion, and is almost unusable as is. > Since, we are at the stabilisation stage of our cycle, I expect many will > start looking at DW and EM, and could really get confused, both by the > different status depending on which list you look at, but even more by the > same package taking different names. > Since we were unable to find an agreement of how to name packages, we are > currently impacting a lot usability. > This also block the automation of the upgrade of extension.xwiki.org to the > latest version, and therefore increase confusion even more, and overcharge > the RM. > So, even if we cannot settle our decision on names, at least we need to > make them consistant ASAP.
This has just been fixed by: * Thomas reverted all my changes to have nice pretty names on e.x.o, the names on e.x.o are now the <name> from the POMs * have committed in http://jira.xwiki.org/jira/browse/XWIKI-8739 the names I had used on e.x.o so that the next release will fix the names on e.x.o We still need to decide what solution we want for the long run. Thanks -Vincent > WDYT ? > > >> Thanks >> -Vincent >> >>> So my vote is: >>> +1 for 1) >>> +0 for 2) >>> -1 for 3) >>> >>> Thanks, >>> Eduard >>> >>> >>> >>> On Tue, Oct 9, 2012 at 2:49 PM, Denis Gervalle <[email protected]> wrote: >>> >>>> On Tue, Oct 9, 2012 at 11:19 AM, Vincent Massol <[email protected]> >>>> wrote: >>>> >>>>> >>>>> On Oct 9, 2012, at 11:09 AM, Thomas Mortagne < >> [email protected]> >>>>> wrote: >>>>> >>>>>> Hi devs, >>>>>> >>>>>> In order to automate the update of extensions imported from >>>>>> https://github.com/xwiki/ we need to have nothing to modify when an >>>>>> import is done. >>>>>> >>>>>> The last remaining thing is the name on which there is a debate is the >>>>>> name. Right now the name we have in our maven project looks like >>>>>> "XWiki Commons - Extension - Repository - Maven" so that's what we get >>>>>> when importing this project or when viewing it in EM UI. >>>>>> >>>>>> Some of us want to keep this idish name for Maven build but don't like >>>>>> it when displaying extension. I recently introduced a way to overwrite >>>>>> some extension related informations like the name based on properties. >>>>>> >>>>>> So here are the choices we have: >>>>>> >>>>>> 1) Do nothing which mean display "XWiki Commons - Extension - >>>>>> Repository - Maven" in EM UI and extensions.xwiki.org >>>>>> 2) Change our naming in Maven <name> property for it to be more a name >>>>>> than an id that would looks good in EM UI >>>>>> 3) Keep the same naming for Maven <name> and overwrite it everywhere >>>>>> using <xwiki.extension.name> property >>>>>> >>>>>> So, WDYT ? >>>>>> >>>>>> The one that makes the more sense to me is 2) so my +1 goes to this >>>>>> one. Frankly I don't care too much having the current id based display >>>>>> of the summary of built modules in Maven build and I personally won't >>>>>> have any issue to know what name correspond to what project (but >>>>>> that's because I know them well, I can understand new dev could be a >>>>>> bit more lost). >>>>>> >>>>>> Then: >>>>>> * +0 for 3) to +0 (I don't like too much having this special case >>>>>> everywhere in our Maven pom.xml) >>>>>> * -0 for 1) (I agree that it does not looks very nice as a display >>>> name). >>>>> >>>>> Exactly the same as Thomas for me. I'd really like if we could find a >>>>> solution that works for 2). Even in Maven it's supposed to be a name, >>>> i.e. >>>>> something readable, not an id… Now even with 2) we would still need a >>>>> naming rule and have some concise name. >>>>> >>>> >>>> If you want name to be more pretty and concise, we should also discuss >> how >>>> the information lost in changing names are still displayed in EM, since >>>> these information are still useful IMO. I take the occasion to also >> mention >>>> that EM currently do not seems to sort the list by any means, and this >> make >>>> the list not really browsable. And if you think about sorting, the >> current >>>> names are not badly suited. >>>> >>>> There is IMO a 4) option, just to be complete since I am not sure I >> would >>>> be in favor, which is to manage the issue in the UI, parsing our names >> and >>>> displaying them differently, to be just more pretty. >>>> >>>> I would prefer to keep only one name, using the maven one, so 2) seems >> the >>>> best option after doing nothing, but I am not really happy to loose the >>>> information we have in names currently. So I agree with Vincent, the >> naming >>>> convention is closely linked to this vote. >>>> >>>> >>>>> >>>>> Thanks >>>>> -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
