Hi Jonathan, Some interaction/consistency/usability feedback for http://jssolichin.com/xwiki/: - the .nav-icons section could work as a toolbar and every action could take you to the appropriate anchor (for example: clicking on the history-clock icon should take you to #history) - not every entry in the toolbar should have a counter, for example Main, History, Info is confusing to have counters. The only relevant counters IMO are the Comments, Annotations, Attachments; - when you are using the .nav-control, the items in the navigation have counters near the type, like "Attachments 3". Would be nice to have this counter too when manually scrolling the navigation, like have the counter not only on .attachments-link but also on #attachments-wrapper h2 - in recent versions of XWiki (since 4.0) Comments are merged with Annotations - good to know that :) - "Main" section content: "Last Modified", "Created", "Tags" can be put in the "Information" section although the last editor could be put near the page title somewhere in order to be able to scan rapidly; - "Main" naming of the section is kind of confusing since "Main" is also the name of a space in XWiki. If you removed the things mentioned above you can call it "Navigation" or something else, since it will contain table of content, quicklinks, recent, etc. (mostly panels content) - you could have a separate "Actions" section that contains page actions: edit, export, etc.
Just for your information, I don't know if you've read my proposal about Collaborative Editing http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CollaborativeEditing Although the topic is different from your project, you can see some mockups of another possible skin for XWiki. Is build with Twitter Bootstrap just like Jerome's Lyrebird. Could be useful to have as inspiration or at least to know about it. Thanks, Caty On Wed, Jun 27, 2012 at 2:24 PM, Jonathan Solichin <[email protected]>wrote: > Hello friends, > > > > The root application >> wikis >> spaces in a wiki >> Pages in a space. > > If you reveal that in the menu users get the intuitive feeling that they > > can create a wiki also. And in a wiki they can have spaces and etc... > > Well the first time I used XWiki my intuition was to use the drop down at > > space to get a list of spaces.I thought the document index would list the > > spaces available. > > Ah ok, I think I understand what you mean. Clarify if I am wrong: on the > bread crumb, you think that it would be a good idea if it listed the > adjacent areas in the drop down. > eg. if you hover over the pages, it will reveal all the pages in the same > space as the current document. > > As a status update. I've done most of the mobile of the skin. Go ahead and > try it in your respective browser: http://jssolichin.com/xwiki. I have > presently tested it on android and Windows Phone along with browser resize > on Chrome. Trying to get my hands on some iphone/blackberry. Let me know > any glaring issues on those browsers in the mean time. > > What do you guys think about my implementation/solution to the sidebar? I > handled the swiping a bit differently than the Coffin example. The issue > with coffin is that it seems that it is not cross compatible. The swipe > gesture does not work on WP7 nor on a browser. If you load coffin in a > browser with a small viewport, you lose the ability to scroll completely > and have no way to access the rest of the pages or the menu (unless i'm > doing it wrong). > > The way I solved this issue is by making the sidebar in a negative > position. In the mobile browser I tested, it seems to disregard this, so > you can still swipe to see the sidebar. But since you can not do this is a > desktop browser, i implemented the links to access it (sort of reminiscent > of WP's right arrow for apps access). Another benefit is that it allows the > browser to natively direct user to a specific div using #. So if I sent > someone a link to http://jssolichin.com/xwiki#attachments, it should load > the webpage in that area (also why I used scrolling instead of tabs). What > do you guys think? > > One thing that I am wondering though is, sometimes a few lines of extra > code is needed to make sure all the feature work properly upon resize. > Should I worry about this? Like if a viewer resizes the browser from a > desktop to a mobile size, should I add extra lines to make sure he can view > it correctly? A lot of this has to do with the resizing capability of the > sidebar (which can't be accomplished with css). > > Next step: implement all the drop down and test compatibility on mobile (as > I can get a hold of them) and firefox/safari/ie. Also, begin porting over > to xwiki/simplifying/standardizing. > > Thanks friends! > JS > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
