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 <supreetpal(a)gmail.com>wrote;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 <supreetpal(a)gmail.com
wrote:
>
>
> On Mon, Mar 28, 2011 at 7:57 PM, Jerome Velociter <jerome(a)xwiki.com
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 <
supreetpal(a)gmail.com>
> wrote:
> > On Thu, Mar 24, 2011 at 8:35 AM, Sergiu Dumitriu <sergiu(a)xwiki.com>
> 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<
> supreetpal(a)gmail.com>
> >> 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
> devs(a)xwiki.org
>
http://lists.xwiki.org/mailman/listinfo/devs
>
--
Thanx,
Supreet
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thanx,
Supreet
--
Thanx,
Supreet
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs