Le 28/04/11 20:02, Thibaut Camberlin a écrit :
I agree about not using the "terms", this is why I mentionned the "simple" view which focus only on the minimum stuff you need to do. Now maybe the simple view could be the same as the "wizard" step which present the minimum stuff to do without actually you having to know what you are actually doing.Hi,Shouldn't this thread be on users ? See my comments below. On Thu, Apr 28, 2011 at 10:39 AM, Ecaterina Moraru (Valica)< [email protected]> wrote:On Thu, Apr 28, 2011 at 10:02, Thibaut Camberlin< [email protected]> wrote:Hi, Thanks Caty for the proposal. Here are my comments on it and on the application that I think we should target: - The progress bar is nice. We could also use a "step" mechanism sincewehave 3 or 4 steps. I am not sure a percentage is relevant.1/4 = 25% 4/4 = 100% this depends on our approach, but the percentages are not related to the number of steps you have and everybody knows that 100% means you're done. We already have the steps completion presented by "checking" the step number http://incubator.myxwiki.org/xwiki/bin/download/Improvements/ApplicationWithinMinutesProposalStructure/helpStepsDetails.pngUsing steps and percentages like you do is ok to me. It is just that it seems to me more accurate to have percentages for sites like LinkedIn where you have a lot of stuff to put in. Steps seems more simple to me.- Since we are in a wizard I think standard buttons "Preview", "Save& Continue" ... etc should be replaced by "<< Previous" and "Next>>"Although you have steps and the user can follow the steps order I tried not to limit the user by this wizard.Having steps using a wizard is more of a way to guide users rather than a limitation. And that is the problem with apps that have percentages to indicate where you are with the action they want you to perform. You see your percentage and wonder where you have to go / what to do to get to 100%. Application Within Minutes should be super simple. Having just 2 buttons "Previous" and "Next" is simpler than 4 "Preview", "Save& View", "Save& Continue" and "Cancel" .... I don't like wizards very much and that's why I didn't add the Prev, Next.The user can follow the wizard or he can do the task in any order he likes.Letting the user do what he wants is great when he knows what he is doing. But we are not targeting advanced users. Guiding users is better in this use case.And this is good for more complex applications: you create a class, create the sheet ... you can always go back and create another class without losing your progress.Again, we need to be able to ship Application Within Minutes without talking about class, sheets, templates. This is "Chinese" for 95% of people out there. I did a training on XWiki today, to people that will be the main contributors on the wiki. They are the kind of people that may create applications using Application Within Minutes. They started laughing when I mentioned the word "Macro" from the WYSIWYG button. Why? Because since the beginning of the session, I used a lot of vocabulary that they did not have an idea what they meant. I don't even notice using them anymore, because us, heavy users of the wiki don't even pay attention to this anymore. That's normal but we really have to pay attention to this. This will not be easy to find the right way to present things, find the right words but if we don't succeed in doing Application Within Minutes without the words "Sheet", "Class", "Template", etc, we will have failed doing the right app IMO.
So maybe the solution is: Steps/Wizard View and Advanced View and you move the wizard steps display on the left with next/previous. The advanced view then allows to get the full list of pages and stuff.I proposed a tree mainly for screen real estate. For advanced user if you applications gets big you'll have a screen real estate issue. So it's necessary to be able to open/close sections and to use smaller sizes. I agree that we need only one level and that it can just be a collapsed system that is not a tree. Just make it smaller IMO
Ludovic
- ColorTheme application example is not a very good example IMO. Basically, users will want to use Application Within Minutes every time they want to manage "entries", à la Excel. So it can be events, products, tasks, people, ... See example given here : http://www.xwiki.com/xwiki/bin/view/Blog/ContentStructuration . Youcanalso check how IWA could have used Application Within Minutes to create this space : http://www.iwawaterwiki.org/xwiki/bin/view/EventsExtra/ (When loggued in, you can contribute material)IMO ColorTheme was great as an example. When I did the proposal I had in mind something that can be used by beginner users and advanced.ColorTheme is XE specific application. The way you edit a color theme is nothing but standard. Since I work at XWiki SAS clients (users) never asked for that type of application for their daily use. Application Within Minutes will never be able (and does not target) to handle that much complexity.I don't think is wise to have 2 separate ways of doing something (one way for the beginner and one way for the advanced people). That's why I choose to display how an already customizable/medium application should be displayed.If having one way to present things means add complexity for beginner then I will be big -1. That is why Ludovic and I suggested to have a simple / advanced way of presenting things.- I don't see the page / area that lists all applications. Is this located in the administration? It would be cool not to have them in the administration.I don't think the area that lists all the application should be in administration. It could be related somehow to the Document Index maybe, because all users could benefit from using the applications. When you want to create an application you should go to the "Add" menu. An application being a space IMO makes sense the application list should be somewhere in the Document Index.Yes, 1 application = 1 space makes sense to me too.
+1 too. This will lead is to the "space type" issue but this is not the subject.
- Application Within Minutes is for end users. Developers already have access to XWiki ability to create applications. Therefore, we shouldnothave any line of code in the default (simple) view.- The first thing that we have to target is the simple view- Here are the items that users in simple view should have access to(andonly): - Application Name - Application Key - Application Description - A page that allows user describe the data he/she wants to manage - Property name - Property type - Application home page options - Welcome message - Does users want to list entries on the home page - Fields to be displayed in that list - Rights settings (maybe not in this version) - Other options? - => Therefore we should not mention class, sheet, template, etc. All this should be transparent for those user (at least in simple view)So from what I see nothing changed from your last vision. You still want everything like you specified in the wireframes. So this means keeping http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMinutesEditorHome http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMinutesEditorPreferences and redo the structure part. In my vision the structure part was the best part, but yes it was not actually intended only for beginner users, but for a mix. Using it also by advanced devs and not having to have a separated environment was the purpose. I liked the fact that you could see all pages related to the structure of the application and IMO this is an improvement from what we currently have. I don't know why a tree would be more suitable, neither of the tree's look and we also don't need the complexity (we have only 2 levels to display).I never suggested a tree. I just did a list of all things that should be input by the user to make its application to work. In the wireframes I suggested there is no tree.- I beleive we can use a default XWiki page, no need to have adedicatedenvironment. If we want to display extra tips we can either use the administration layout or panels.If we remove the header is just a simple XWiki page. But the header gave unity and enforced the stepped creation process. If you make it just a simple page than how would you know it is an application?I like the header. The panels are not needed if we are doing the app simple because the tips can be display in the regular new form standards, and sheet, template etc. can be removed. Thanks, ThibautThanks for the feedback, CatyThanks -- Thibaut On Mon, Apr 25, 2011 at 10:03 PM, Ludovic Dubost<[email protected]> wrote:Hi, Here is some feedback about the proposal. Generally I like the proposal which covers mostly what we need. I see some ntegration issue however: - the structure of the page is different than a normal "xwiki" page.Thisis a problem I think. I'm not sure how this will integrate in the restofXWiki. This probably means there should be some way to customize the"homepage" look. - it's not clear where the application resides, wether it is in the"prefs"or somewhere in the wiki and how we access it. Some comments about the UI itself: Main Screen: - "Add New Entry" should not have a page name. One of the objectivesofthe project is to get rid of this requirement. It should only be an"Add"button. Structure Screen: - I'm not sure about the left vertical zone with the different pagetypes.Your proposal is kind of "IDE view". For an "IDE view" I would prefer a tree. But I think we first need an "simple view", so I believe weshouldpropose 2 views: Simple / Advanced. - Simple View: - Show only the minimun actions: Class, Templates, Translations - We don't need "Sheet" in the simple view as it should be thedefaultscript. In "simple" mode no script should be necessary. - IDE View: - Show a tree with all the different page types. Each page type should have some more advanced proposals to help edit.Themost important one is the "Class Editor". We need a simpler proposal.Weshould look at applications on the web (google forms or so) whichproposesome simple ways to add and edit fields. This could mean merging "class editor" and "sheet editor" but I'm not sure we are ready for that yet. For "Sheets" we need a way to associate "Sheets" with edit modes (view/edit / search / changes / home), but that's advanced mode too. For Translations initially it would be the usual wiki editing, but thenweshould propose an editor. The main priority I see for the next steps are: - propose a "simple view" - propose a simpler class editor - clarify/fix integration issues for the home page / define entry pointofthe App Within Minutes app - propose an edit view for translations In general it's ok that we think "long term" (IDE style in advancedmode,more advanced editors), but we can already deliver something compellingwithall the "default options" used instead of providing too many features. Let's make sure we have a clear definition of the "minimum" so that developers know what to start with. Looking forward for the next cycle. Ludovic Le 22/04/11 18:54, Ecaterina Moraru (Valica) a écrit : Hi,I've made a proposal with my vision for the Application Within Minutes idea ( http://dev.xwiki.org/xwiki/bin/view/Design/ApplicationWithinMinutes) The proposal can be found at:http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMinutesProposalAdditional details for the "Structure" area at:http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMinutesProposalStructureCurious of what you think about it. Thanks, Caty----------------------------------------------------------------------------------------------------------------------------------------------Prototypes (they are linked one from another): * Home:http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMinutesEditorHome* Structure:http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMinutesEditorClasshttp://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMinutesEditorSheet* Preferences:http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ApplicationWithinMinutesEditorPreferences_______________________________________________ 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
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
<<attachment: ludovic.vcf>>
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
