On Fri, Mar 21, 2014 at 1:41 PM, Clemens Klein-Robbenhaar < [email protected]> wrote:
> On 03/21/2014 08:35 AM, Ecaterina Moraru (Valica) wrote: > > On Thu, Mar 20, 2014 at 2:37 PM, Clemens Klein-Robbenhaar < > > [email protected]> wrote: > [....] > >> The new details view looks good; however I wonder what the "View" > >> button does. Is this an alternative to "Edit", e.g. depending on the > >> view/edit mode one sees a button to switch to the other one? > >> > > > > I've mentioned what the buttons are suppose to do in > > > http://jira.xwiki.org/browse/MOCCACAL-13?focusedCommentId=80201&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-80201 > > 'View' should direct to the event page, in view mode, allowing viewing of > > comments, attachments, etc. > > The functionality is similar to our 'Quick Jump' (Ctrl + G), but I've > > changed the order of importance for Edit and View. > > > Ah, I should not only have looked at the screens, but should also have > read the issues :) > > Actually I first planned to keep users away from the "full view" of the > event page, > but indeed I forgot about the option to add attachments etc. which is not > possible > in the small dialog. > I wonder if a better label but "view" can be found, because, well, I am > already viewing > the event. Maybe "More" or "Details" or ... well, never mind, "View" is at > least > good enough for now, anything I can think of is either too long or > inaccurate. > > > > >> > >> For the Panels: > >> > >> - if there are many calendars (e.g. if every user creates ones own > >> calendar) > >> then the panel for filtering the calendars one wants to see will not > >> scale well, if it lists all calenders available. (However it will be > >> more needed then ever, of course :) > >> However as I have no good idea how to handle the case of very many > >> calendars, > >> I am happy to get this panel working first. > >> > > > > We could list a fix number of calendar (5-10) and have a 'More' that > lists > > more calendars. We have a similar effect in Solr Search facets. > > > Yes, this would an option. But what criteria decides which calendars make > it to the list > of the first 5-10 calendars? Just sorting them alphabetically will always > list > the same ones. Maybe the ones "with the most upcoming events" ... but I am > not > sure if this is not a possibly expensive query. > > I thought about having a two-fold UI: > - if there are less than 5-10 calendars, just show them all > - if there are more, show the ones the user is subscribed to, > and an input field with autocompletion to search for other calendars to > add to the list > I think this scraped well with the number of calendars (not with the > number of subscribed calendars, however) > However I am not sure if switching between two different UI's depending on > the number of calendars is a good idea ... > Another thing to consider when doing prioritization is displaying the calendars that are 'enabled' (displayed in the view) vs. the one that exist, but that are not interesting for the current user. > > > > >> > >> - This panel also needs a way to store some kind of "User Preferences" > >> for the Calendar. I think this is a good idea, but I am not sure how > >> to implement this. (Is adding a "MoccaCalendarPreferences" object to > >> the > >> user profile acceptable? I am not sure if this makes the users > profile > >> unusable if someone uninstalls the application that has defined the > >> prefs.) > >> > > > > IMO this is acceptable. We have done it in the past for Dashboard, > > Watchlist, Workspaces, etc. and let the user have his preferences defined > > in his User Profile. In Flamingo's proposal, I've clearly separated the > > Application's preferences in a special section in the vertical-menu > > > http://design.xwiki.org/xwiki/bin/download/Improvements/Skin4xProfile/profileDesktopLandscape.png > > > > Adding new sections in the User preference pages would be nice, at least > from the application developer point of view. > I wonder what the users think of it after having N different > application settings in their profile ... but I see in the proposal > these are already listed in a separate "Applications" menu, > so folks can ignore then until they need them. > > > > > > >> > >> - What does the "little calendar" panel in the lower right do? > >> I guess it is just to show it on the same page as the other calendar > >> related panels, because it would be good to have this panel > elsewhere > >> to be able to jump to the calendar, but that might be of not much > use > >> inside the calendar app itself? > >> Or maybe I am misunderstanding what it is good for. > >> > > > > The Calendar proposal is very similar to Google Calendar. > > The nice thing about the panels is that they could be reused also in > other > > applications (spaces). It just displayed the current month and day. > Having > > it for navigation could be interesting, but complicated from > implementation > > point of view. > > > > Ah, I never looked at Google Calendar (really). > I actually expected it to do more than just display the current month, but > I agree > it is complicating the implementation considerably, whatever it is. > > > > >> > >> About view order: > >> > >> - Why is "Day, Week, Month, Agenda" better than "Month, Week, Day, > >> Agenda" ? > >> (just asking, I do not understand the rationale) > >> Btw, the "Month, Week, Day" order just happen to be the default for > full > >> calendar, that is the rationale why it is the way it is now. ;) > >> > > > > 'Day', 'Week', 'Month', 'Agenda' is the order also defined in Google > > Calendar, Yahoo Calendar, Apple Calendar, etc. Having the same layout and > > pattern throughout calendar applications is good. > > > > Ah, that's why. > Seems I have been living in a cave and ignored the current standards about > calendars :) > :) I agree with the rest of your comments. Thanks, Caty > > Cheers, > Clemens > > > > >> > >> I feel the best order depends on how many events are in the calendar. > >> For example if there are only a few, say, it contains milestones > >> for a software release, the "month view" is the one that will be > >> used most. > >> Well, I guess I am asking for making this configurable. I have a > >> vague feeling that this will come back to me :D > >> > >> Calendars: > >> > >> - the reasons that the view to add calendars is now on the main page > >> is that users do not miss that they can add their own calendars. > >> However I understand that this is not the best way to get a high > >> usability/area ratio, as one only rarely adds new calendars > >> The proposal is to move that to a separate page, which I agree, > >> and to show a "settings" button to get to that page. Where > >> I am not sure is if "Settings" is a good label - I would not expect > >> to find the ability to add new calendars in "Settings". > >> I would have preferred something like "Manage Calendars". > >> (However I have to admit that this makes the label quite long ...) > >> > > > > At first can be called 'Manage Calendars' if you prefer. In my mind, the > > 'Settings' should be extended in the future with the ability to adjust > the > > timezone, starting day of the week, export calendars, etc. > > > > > >> > >> - for every calendar there are "add / edit / actions" in the screens. > >> I guess that is just the default that XWiki offers for every page? > >> Sometimes I wonder if allowing an application to hide some of the > >> menu options would be good. (E.g. exporting a calendar to PDF > >> is possible, but the result looks nowhere like what the user might > >> expect; > >> it is mostly a blank page.) > >> > > > > I've tough about that. The problem is that currently our menus do not > have > > extensions points. In the future menus could be personalized per > > application, or incorporate the application's custom buttons inside (like > > being able to Add - Event from the content Add). I know it's not perfect, > > but for the current layout and implementation both content and > applications > > actions should be visible (in order to be able to add pages, export, > etc.) > > > > Thanks :) > > Caty > > > > > >> > >> > >> > >> Clemens > >> > >>> > >>> Thanks, > >>> Caty > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
