Hey I have submitted my proposal on melange , I hope you will all will go through it and leave valuable comments so that I can improve upon it.
On Wed, Mar 30, 2011 at 1:21 PM, Ecaterina Moraru (Valica) < [email protected]> wrote: > IMO the skin will not change the back-end but affect just the view. It may > need to do some optimizations on the loading for mobile, maybe disable some > modules that are not used by the mobile skin, but I'm not sure how this > should be done. > > Thanks, > Caty > > > On Tue, Mar 29, 2011 at 23:38, Supreet Pal Singh <[email protected]>wrote: > >> Hey, >> I was a little confused as to how we would go about developing the backend >> of the mobile skin as it seemed that everyone was interested in the >> development being done from scratch with only the required functions and >> code that would be loaded. Are there any pre existing modules to link the >> server and database with the newly developed skin or are we just going to >> develop a restricted UI/skin for mobile web-browsers with no changes on >> the >> backend? >> >> On Tue, Mar 29, 2011 at 2:06 AM, Supreet Pal Singh <[email protected] >> >wrote: >> >> > >> > >> > On Mon, Mar 28, 2011 at 7:57 PM, Jerome Velociter <[email protected] >> >wrote: >> > >> >> Hi Supreet >> >> >> >> Great to see you took the time to work on this. >> >> >> >> My remarks below >> >> >> >> On Fri, Mar 25, 2011 at 8:51 PM, Supreet Pal Singh < >> [email protected]> >> >> wrote: >> >> > On Thu, Mar 24, 2011 at 8:35 AM, Sergiu Dumitriu <[email protected]> >> >> wrote: >> >> > >> >> >> On 03/23/2011 02:27 PM, Jerome Velociter wrote: >> >> >> > Hi Supreet, >> >> >> > >> >> >> > Great to see your interest in this project. >> >> >> > >> >> >> > On Wed, Mar 23, 2011 at 2:04 PM, Supreet Pal Singh< >> >> [email protected]> >> >> >> wrote: >> >> >> >> Hey Caty, >> >> >> >> Thanx :) >> >> >> >> Also,I went through those links and the sketches heres what I >> think: >> >> >> >> >> >> >> >> 1. Jerome's version does look better and simple but I feel it >> would >> >> lack >> >> >> the >> >> >> >> ease of use as most of the functions would be present in a >> separate >> >> menu >> >> >> >> which could be reached through the '+' . More clicks leads to a >> less >> >> >> >> intuitive UI and downgrades user experience. On the other hand, >> >> Jerome's >> >> >> >> version gives a lighter and better look with only the main >> functions >> >> on >> >> >> the >> >> >> >> homescreen. What needs to be looked into is whether the main >> options >> >> are >> >> >> >> sufficient to cater an average user such that we can ignore the >> >> 'more >> >> >> >> clicks' aspect. >> >> >> >> What I have also noticed is that Jerome's version does include >> all >> >> the >> >> >> >> functions present on yours yet has an option '+' and even your >> >> version >> >> >> has >> >> >> >> an empty function box so I am guessing there are/would be more >> >> functions >> >> >> >> that need to be present or added. >> >> >> >> Personally, I am in favor of your version of the skin because its >> >> >> functions >> >> >> >> serve as tabs for dynamic lower portion of the screen, the static >> >> layer >> >> >> of >> >> >> >> links to the various functions/screens makes it easy to navigate >> for >> >> the >> >> >> >> user. >> >> >> > >> >> >> > Couple of remarks : >> >> >> > >> >> >> > * It's maybe not obvious, but in my sketch the lower bar is >> static, >> >> so >> >> >> > you don't have to scroll for it, it always remains at the bottom >> of >> >> >> > the user screen >> >> >> > * As I tried to explain in my comment, I tend to think base use >> case >> >> >> > of a mobile version is about searching + reading content and >> comment >> >> + >> >> >> > annotations. I think edit is a marginal use case. Does not mean it >> >> >> > should not be doable, but IMHO it should not be considered a >> primary >> >> >> > action. OTOH a good and accessible search is a must have. That's >> why >> >> >> > in my version the search bar is first class citizen, at the top of >> >> the >> >> >> > page. >> >> >> > * The search would be a dynamic one, a bit in the spirit of the >> >> search >> >> >> > suggest available since XE 3.0 (best is to check the feature in >> the >> >> >> > version in 3.0 RC1, due today) >> >> >> > >> >> >> >> >> >> >> >> 2. Even I feel that the two scrolls on the comments page should >> be >> >> done >> >> >> away >> >> >> >> with instead it should take the whole page. >> >> >> >> >> >> >> >> >> >> >> >> And I am new to XWiki and its development tools so I would be >> >> needing >> >> >> your >> >> >> >> help to get on track so please bare with my newbie questions. >> >> >> >> 1. I have downloaded 'xwiki-enterprise-installer-generic-3.0' and >> >> would >> >> >> be >> >> >> >> following the instructions as given on >> >> >> >> http://platform.xwiki.org/xwiki/bin/view/DevGuide/Skins , is >> this >> >> the >> >> >> >> correct approach? >> >> >> > >> >> >> > Yes it's an approach that would work. >> >> >> > Also I think the mobile skin is about dropping tons of stuff, so >> >> >> > another approach would be to create a new skin from scratch and >> build >> >> >> > it keeping only on what is essential (to have good performances). >> >> >> >> >> >> An interesting article I read recently summarizes how the iphone, >> ipad >> >> >> and desktop versions of the top websites differ in transfer size, >> DOM >> >> >> size, and number of HTTP requests. >> >> >> >> >> >> http://www.stevesouders.com/blog/2011/03/14/mobile-comparison-of-top-11/ >> >> >> >> >> >> The results are a bit mindblowing. These sites go to great lengths >> to >> >> >> offer the best performance on mobile devices (for example storing >> >> static >> >> >> portions of the HTML page in Local Storage to save on transfer), so >> >> >> making a mobile version of a site could involve a lot more changes >> than >> >> >> just shuffling things around with a bit of more CSS. For best >> results, >> >> a >> >> >> whole new skin should be written (meaning lots of .vm templates). >> >> >> >> >> >> The problem with this approach is that it will duplicate code, >> making >> >> it >> >> >> harder to change things in the templates. >> >> >> >> >> > >> >> > >> >> > Hey, that was a very nice article :) Hopefully we ll also be able to >> >> > optimise XWiki very effectively for mobile devices. Also, I need some >> >> help >> >> > as to how I can about start writing the project code to develop the >> skin >> >> > from scratch. >> >> > >> >> >> >> >> >> >> 2. What else can I do to get a better know how and integrate >> myself >> >> more >> >> >> in >> >> >> >> the project? >> >> >> > >> >> >> > An idea could be you spend some time investigating how other wikis >> >> >> > have designed there mobile version (wikimedia one is interesting, >> but >> >> >> > I'm sure there are others) and refine on the design proposals Caty >> >> and >> >> >> > I made with your own ones, what do you think ? >> >> >> > >> >> >> >> >> >> >> >> > After giving it quite some thought here's my take on the Mobile Skin >> >> > proposals: >> >> > # I believe that keeping a static bar of functions/tabs on top would >> be >> >> more >> >> > convenient than the one at bottom due to the fact that it would lead >> to >> >> a >> >> > lot of clutter and presence of a lot of active buttons in a small >> amount >> >> of >> >> > space. >> >> > Here ( http://www.x.supreetpalsingh.com ) ,If we have a look at the >> >> image >> >> > on the right where I have tried to demonstrate as to how the edit >> page >> >> would >> >> > look on the skin suggested by Jerome with functions at the bottom of >> the >> >> > page, we can clearly see that the bottom of the page is filled with a >> >> lot of >> >> > active links/buttons making it less user friendly and inconvenient to >> >> use. ( >> >> > Inconvenience may not be obvious but the clutter can easily be >> observed >> >> ) >> >> >> >> You are mixing stuff here. My proposal is about a "view page" mode. So >> >> the bottom bar is all you get, there is no such "save", "info" add >> >> pictures etc. in the proposal I make. >> >> I think it's important at this point to well differentiate the "view" >> >> and "edit" UIs. In my view, the edit UI should be modal, just as it is >> >> on the "desktop skin". This translate by no other button than >> >> "preview", "save" and "cancel". Yes, the rest disappear, no search >> >> bar, no lower toolbar with "delete" or "infos" buttons (those are >> >> actions related to the page and accessible when in "view" mode). >> >> Add picture could stay, but that's different, that's a component of >> >> the edit UI (same as we have "insert image" when editing a page with >> >> the WYSIWYG). >> >> So there is no such clutter at the bottom of the UI, since there is >> >> just the "toolbar" (even though I'm not a fan of this name, "action >> >> bar" is probably better) in view mode ; and the "buttons bar" ("save", >> >> "view", "cancel") in edit mode. >> >> >> >> Oh yes, I was mixing up because I thought the "action bar" was static >> > through all the screens that would be available on the skin, hence I >> also >> > considered it to be a navigation bar. A different edit UI as described >> > above according to me is very good as it would allow maximum space to be >> > utilized by the main screen rather than navigation or action buttons. >> > Also, what still needs to be decided or is unclear to me is what all >> > functions/actions need to be included in the mobile skin and hence if >> there >> > is any need of the ' + ' (I will now on call the 'more' option ) . I , >> > personally am not in favor of including a 'more' option and even if need >> to >> > include more actions , we could reduce the size of each a bit because as >> you >> > said "The action bar buttons don't have to be big. They need to be big >> > enough so that you can touch them easily even with big fingers." though >> > earlier my point was that if we can accommodate more space for each >> action >> > button with a little modification of appearance and without losing on >> any >> > functionality I would consider it to be an improvement. >> > >> > >> > > # Also two static bars (Search<top> and Functions<bottom>) will not be >> >> very >> >> > useful as it would consume a lot of space and leave relatively less >> >> space >> >> > for the main content of the page which can be displayed without >> >> scrolling. >> >> >> >> For me the search bar should not be static. It's at the top so that >> >> it's easily accessible when you first display a page, since it's >> >> something you often want to reach for immediately (scenario : I open >> >> my wiki, I search for a page, I read it, I comment it, etc.). But when >> >> you start reading the page, it's not so important to have it available >> >> on the screen. >> >> >> > I totally agree on that but I assumed the search bar to be static >> because >> > there was no reference by you earlier if it would be static or not so I >> > thought >> > it would be best to assume a worst case scenario. >> > >> >> >> >> > # The design proposal by Caty is according to me better but there >> can >> >> be a >> >> > few changes to improve user experience. >> >> > For Example , on the same link above if we observe the image on the >> left >> >> I >> >> > have done away with big XWiki logo which was present earlier with the >> >> tabs >> >> > instead inserted a thin horizontal title bar above them. This leads >> to >> >> two >> >> > things: >> >> > 1. Increased space per tab which is very useful since we are >> targeting a >> >> > 'touchscreen' audience and the larger the tab the more user friendly >> it >> >> is . >> >> > 2. If we decide to maintain the previous the size of the tabs we get >> >> room to >> >> > accommodate one more tab/ function. >> >> >> >> The action bar buttons don't have to be big. They need to be big >> >> enough so that you can touch them easily even with big fingers, but >> >> that's about it. In my opinion you can 8 without problem. >> >> >> >> Jerome >> >> >> >> >> >> > >> >> > What do you think? >> >> > >> >> > '- >> >> >> Sergiu Dumitriu >> >> >> http://purl.org/net/sergiu/ >> >> >> _______________________________________________ >> >> >> devs mailing list >> >> >> [email protected] >> >> >> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> >> >> > >> >> > >> >> > >> >> > -- >> >> > Thanx, >> >> > Supreet >> >> > _______________________________________________ >> >> > devs mailing list >> >> > [email protected] >> >> > http://lists.xwiki.org/mailman/listinfo/devs >> >> > >> >> _______________________________________________ >> >> devs mailing list >> >> [email protected] >> >> http://lists.xwiki.org/mailman/listinfo/devs >> >> >> > >> > >> > >> > -- >> > Thanx, >> > Supreet >> > >> > >> >> >> -- >> Thanx, >> Supreet >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > -- Thanx, Supreet _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
