17 May
2012
17 May
'12
5:57 p.m.
Hello friends
New quick mock up at the very end.
The main problem with this proposal is that you
don't consider and maybe
you are not aware of XWiki's states and that the content in a wiki is
mostly dynamic:
The main problem with this proposal is that you don't consider and maybe
you are not aware of XWiki's states and that the
content in a wiki is
mostly dynamic:
- logged-in vs. logged-out content: The menus have many entries and the
way
you represented them does not scale. Check out the menus structure
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActionMenuProposal…
was the initial proposal, but some menu entries have changed since
then, but the mockups are ok to give you the impression of the entries).
This is true, I knew the mock up had a lot of static element that would
need some more thinking to make it dynamic. I just wanted to get a feel for
this kind of skin since I still wasn't sure how much creativity I
had--thought I have that answered now ahaha.
- empty vs. populated entries: This concerns 'Tags' and 'Comments'
section.
You're put 'Tags' and the
'Welcome' message on the same level because they
both have 3 rows of content, but this is not the case when 'Tags' are used
and populated (you will not have this consistency any more). When you are
logged-in, the 'Comments' section has another structure and would be
interesting to see how you want to display a comment too. Also you've
removed the 'Activity Stream' which is an important part.
Have a look at
http://incubator.myxwiki.org/xwiki/bin/view/Main/WebHomewhich
shows a wiki instance used: there are lots of spaces, lots of
activity entries, some tags, some comments.
Thank you for this link! I had a copy of XWIKI installed, but there was
nothing in it, so it did not help much. (eg. activity streams and so forth)
There is a Forum view of the mails
http://dev.xwiki.org/xwiki/bin/view/Community/Forum
but I don't find it
very useful. Alternatives to see the mailinglists:
http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists#HForums
Thank you, this has been very helpful in seeing the thread, And yes, i need
to get used to it aha.
- I think you underestimate time for both design and implementation.
Remember that in addition to the work it represents by
itself, which
in my opinion is already underestimated, you will have to present it
and discuss it with the community, refine accordingly, etc. This takes
more time that you imagine.
An improvement would be instead of having
just the numbers to put 'Week x.x:' in your timeline.
Also please add the calendar week number as Caty
suggests so that we
have a better view of when things happen.
Yes, this is what I needed, I really was not sure at all how the timeline
was working out. Thank you. I haven't yet updated the timeline, because I
think I need to think on it a bit more, since it seems I have done a lot of
underestimation.
- I don't know what you exactly mean under
"typography check", but a
priori one week sounds way too much for this
- what do you mean by "bumper" ?
Typography check is to check the text, actually the whole skin, on multiple
devices since some superphones have screens that are close to desktop in
resolution (eg. gNEX). So It was more to check whether the skin is
translating well given this circumstance. I thought this might take
slightly longer because of the need to hunt down these phones to check.
Bumper is to make sure everything can still follow the timeline--sort
of--in case I underestimated (which I did a lot aha)
- I think what you have as refinements in week 10
"color variations,
inverse for night time" etc. you can just forget about that. That's
not really important, and it's not likely we can go this far during
the time of the GSoC.
Ok. Thank you for the info.
How much creativity ? A lot :) As much as you can afford !
While there are some good ideas in your skin proposal,
to be honest it
still does feel too much as "dressing up [the] product with a
last-minute garment" as Dieter Rams put it in this great text "Good
Design As A Key Business Advantage" [1].
What we want you to do is to take ownership of the product. Caty is
definitely right when she says you don't consider enough how XWiki
works. You should download XWiki on your computer, install it, plays
with it, get to know its feature, its *purpose*, and then start afresh
on a white (I mean transparent) sheet.
Right now your design has "colibri" written all over it. We can tell
from the links at the top and from the block in the footer. We can
tell from the way you've placed the "annotations" feature, etc. you
get the point. I hope you can make it as if you would never had seen
colibri.
Ok sorry, still testing out the waters. I thought the last proposal was
crazy enough--oops. And getting rid of Colibri in my head is harder than I
thought! As afforementioned I do have XWIKI installed, but it is pretty
barren and I still haven't gotten used to it. Caty's (should I be calling
her that) link with a populated XWIKI will help me with this. Also still
need to finish building from sources as well (doing that on ubuntu to pull
from git, but i'm new to that as well).
In any regards, here is another iteration, quick un-complete mock up
(Content space is white for now, just demoing menu/layout idea) since I
just fleshed some of the ideas in my head and haven't had the time to
completely flesh it out. I was wondering what you guys were thinking of it
though, before I invest more time.
http://jssolichin.com/public/3/desktop.jpg
http://jssolichin.com/public/3/desktop2.jpg
http://jssolichin.com/public/3/desktop3.jpg
http://jssolichin.com/public/3/desktop4.jpg
http://jssolichin.com/public/3/mobille.jpg
http://jssolichin.com/public/3/mobille2.jpg
http://jssolichin.com/public/3/mobille2.jpg<http://jssolichin.com/public…
This design divides navigation into 3, corresponding with borders. As the
user hovers nears the edge, it would reveal the whole link/more info. The
overflowed text serves to give them the idea there is more. By putting the
navigation in the borders, it becomes more static in a way--that is on each
new page, the "navigation links" placement will always be the same area.
Also, by detaching the links from the content, its size has more
flexibility allowing it to be bigger without interrupting the flow of
text-- allowing for bigger size clickable area.
In the mobile version, instead of hovering, the user would click. So it's a
bit similar to the Mobile Patterns[1] link Caty sent a while back since it
is like a sidebar to be revealed kind of thing.
Furthermore, this skin will really put the content front and center. And
again, this mockup is incomplete, i just wanted to give you a heads up on
this current exploration and was wondering your thoughts.
Again sorry, I'm still trying to get used to everything. Thank you for all
the inputs. I hope to be able to ramp up communication once school is
out--nearing critical point atm so a little bit busy.
Thanks all!,
Jonathan Solichin
[1] http://mobile-patterns.com/
18 May
18 May
1:25 p.m.
New subject: [xwiki-devs] [GSoC] Responsive Skin
Hi,
On Thu, May 17, 2012 at 6:57 PM, Jonathan Solichin <jssolichin(a)gmail.com>wrote;wrote:
Hello friends
New quick mock up at the very end.
Yes, you can call me Caty (since that is how I sign my mails) :)
Regarding playing with XWiki, you should use the .ZIP version if you want
to play quickly with XWiki.
You can download the version from
http://enterprise.xwiki.org/xwiki/bin/view/Main/Download
or
http://maven.xwiki.org/releases/org/xwiki/enterprise/xwiki-enterprise-jetty…
Right now the latest version is 4.1-milestone-1.
The main problem with this proposal is that you
don't consider and maybe
you are not aware of XWiki's states and that the content in a wiki is
mostly dynamic:
The main problem with this proposal is that you don't consider and maybe
you are not aware of XWiki's states and that
the content in a wiki is
mostly dynamic:
- logged-in vs. logged-out content: The menus have many entries and the
way
you represented them does not scale. Check out the menus structure
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActionMenuProposal…
was the initial proposal, but some menu entries
have changed since
then, but the mockups are ok to give you the impression of the entries).
This is true, I knew the mock up had a lot of static element that would
need some more thinking to make it dynamic. I just wanted to get a feel for
this kind of skin since I still wasn't sure how much creativity I
had--thought I have that answered now ahaha.
- empty vs. populated entries: This concerns 'Tags' and 'Comments'
section.
You're put 'Tags' and the
'Welcome' message on the same level because
they
both have 3 rows of content, but this is not the
case when 'Tags' are
used
and populated (you will not have this consistency
any more). When you are
logged-in, the 'Comments' section has another structure and would be
interesting to see how you want to display a comment too. Also you've
removed the 'Activity Stream' which is an important part.
Have a look at
http://incubator.myxwiki.org/xwiki/bin/view/Main/WebHomewhich
shows a wiki instance used: there are lots of spaces, lots of
activity entries, some tags, some comments.
Thank you for this link! I had a copy of XWIKI installed, but there was
nothing in it, so it did not help much. (eg. activity streams and so forth)
There is a Forum view of the mails
http://dev.xwiki.org/xwiki/bin/view/Community/Forum but I don't find it
very useful. Alternatives to see the mailinglists:
http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists#HForums
Thank you, this has been very helpful in seeing the thread, And yes, i need
to get used to it aha.
- I think you underestimate time for both design and implementation.
Remember that in addition to the work it
represents by itself, which
in my opinion is already underestimated, you will have to present it
and discuss it with the community, refine accordingly, etc. This takes
more time that you imagine.
An improvement would be instead of having
just the numbers to put 'Week x.x:' in your timeline.
Also please add the calendar week number as Caty
suggests so that we
have a better view of when things happen.
Yes, this is what I needed, I really was not sure at all how the timeline
was working out. Thank you. I haven't yet updated the timeline, because I
think I need to think on it a bit more, since it seems I have done a lot of
underestimation.
- I don't know what you exactly mean under
"typography check", but a
priori one week sounds way too much for this
- what do you mean by "bumper" ?
Typography check is to check the text, actually the whole skin, on multiple
devices since some superphones have screens that are close to desktop in
resolution (eg. gNEX). So It was more to check whether the skin is
translating well given this circumstance. I thought this might take
slightly longer because of the need to hunt down these phones to check.
Bumper is to make sure everything can still follow the timeline--sort
of--in case I underestimated (which I did a lot aha)
- I think what you have as refinements in week 10
"color variations,
inverse for night time" etc. you can just forget about that. That's
not really important, and it's not likely we can go this far during
the time of the GSoC.
Ok. Thank you for the info.
How much creativity ? A lot :) As much as you can afford !
While there are some good ideas in your skin
proposal, to be honest it
still does feel too much as "dressing up [the] product with a
last-minute garment" as Dieter Rams put it in this great text "Good
Design As A Key Business Advantage" [1].
What we want you to do is to take ownership of the product. Caty is
definitely right when she says you don't consider enough how XWiki
works. You should download XWiki on your computer, install it, plays
with it, get to know its feature, its *purpose*, and then start afresh
on a white (I mean transparent) sheet.
Right now your design has "colibri" written all over it. We can tell
from the links at the top and from the block in the footer. We can
tell from the way you've placed the "annotations" feature, etc. you
get the point. I hope you can make it as if you would never had seen
colibri.
Ok sorry, still testing out the waters. I thought the last proposal was
crazy enough--oops. And getting rid of Colibri in my head is harder than I
thought! As afforementioned I do have XWIKI installed, but it is pretty
barren and I still haven't gotten used to it. Caty's (should I be calling
her that) link with a populated XWIKI will help me with this. Also still
need to finish building from sources as well (doing that on ubuntu to pull
from git, but i'm new to that as well).
In any regards, here is another iteration, quick un-complete mock up
(Content space is white for now, just demoing menu/layout idea) since I
just fleshed some of the ideas in my head and haven't had the time to
completely flesh it out. I was wondering what you guys were thinking of it
though, before I invest more time.
http://jssolichin.com/public/3/desktop.jpg
http://jssolichin.com/public/3/desktop2.jpg
http://jssolichin.com/public/3/desktop3.jpg
http://jssolichin.com/public/3/desktop4.jpg
http://jssolichin.com/public/3/mobille.jpg
http://jssolichin.com/public/3/mobille2.jpg
http://jssolichin.com/public/3/mobille2.jpg<
http://jssolichin.com/public/3/mobille3.jpg>
This design divides navigation into 3, corresponding with borders. As the
user hovers nears the edge, it would reveal the whole link/more info. The
overflowed text serves to give them the idea there is more. By putting the
navigation in the borders, it becomes more static in a way--that is on each
new page, the "navigation links" placement will always be the same area.
Also, by detaching the links from the content, its size has more
flexibility allowing it to be bigger without interrupting the flow of
text-- allowing for bigger size clickable area.
In the mobile version, instead of hovering, the user would click. So it's a
bit similar to the Mobile Patterns[1] link Caty sent a while back since it
is like a sidebar to be revealed kind of thing.
This kind of progressive disclosure mechanism that you've used for the
Desktop version is good for the mobile versions, when the space is limited.
But on desktops I think is gonna be very disruptive for the user to
hide/show such large portions of UI, especially on hover events (which can
be triggered by accident). On desktop you have lots of space to use and the
navigation/tools elements should be visible and accessible. So your desktop
version would work better as a mobile version, but on landscape.
On the 'content is the king' note, I just wanted to state that XWiki is an
application wiki. So you need to have in mind that 'content' means not just
text, but application content: forms, links, text, attachments, etc. The
'content' thing is the hard part in representing it in a responsive manner.
You should take a look at XWiki's features
http://enterprise.xwiki.org/xwiki/bin/view/Main/Features
in order to get a better sense of what you can add. Also check out our
Extensions
http://extensions.xwiki.org/xwiki/bin/view/Main/WebHome#|t=extensions&p…
Can't wait to see more from you and good luck with school.
Thanks,
Caty
Furthermore, this skin will really put the content front and center. And
again, this mockup is incomplete, i just wanted to give you a heads up on
this current exploration and was wondering your thoughts.
Again sorry, I'm still trying to get used to everything. Thank you for all
the inputs. I hope to be able to ramp up communication once school is
out--nearing critical point atm so a little bit busy.
Thanks all!,
Jonathan Solichin
[1] http://mobile-patterns.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
20 May
20 May
12:40 a.m.
New subject: [xwiki-devs] [GSoC] Responsive Skin
For a truly responsive skin, might be interesting to consider some
design alternatives to the traditional -- such as "windows metro" :
http://en.wikipedia.org/wiki/Metro_(design_language)
One could, for example, use the notion of partially clipped text on
the left and right sides of the page to indicate that the mobile
screen could be swiped left or right, thereby exposing parts of the UI
that couldn't fit on a small screen. This could be used to hint at
presence of left/right side-bar content of a normal XWiki page, even
when displayed on a small screen.
Alternatley, the technique could also be used to break up a
traditional wiki document of linear sections, into a "metro style
panel" of horizontal pages. So in order to read within the section,
you'd swipe downward till you hit bottom of the section. But there'd
be a hint of the section header following and preceding to the right
and left. To go to the new section of a document, you'd therefore
sweep rightward; to go to previous you'd sweep left.
The following document talks about going from "website to metro-styled
app" but the same concept could be used to use a skin to transform
existing Wiki/Website layout to a mobile-friendly metro-styled design:
http://msdn.microsoft.com/en-us/library/windows/apps/hh868264.aspx
Some examples:
http://conversations.nokia.com/
http://justinangel.net/
http://justinangel.net/Windows8MetroBlog
http://css.dzone.com/articles/html5css3javascript-framework
http://www.behance.net/gallery/Metro-Style-Website-Template/3281283
http://theinspirationroom.com/daily/2011/microsoft-research-20-years/
-- Niels
http://www.nielsmayer.com
21 May
21 May
10:55 p.m.
New subject: [xwiki-devs] [GSoC] Responsive Skin
Hi Niels,
Thanks for popping in, very insightful links.
BTW the GSoC title says "Responsive skin" ; but in terms of
implementation I have nothing against what LukeW calls "RESS"
(http://www.lukew.com/ff/entry.asp?1392) which basically says it's OK
to have some part of templates be device specific.
The only issue is that AFAIK there's no mature open source server side
device detection library available just yet. There are some available
based on regexes, but they mostly will recognize a mobile UA ; not
tablets or TV or etc. There are more advanced detection possible with
things like WURFL http://wurfl.sourceforge.net/, but their data is not
open.
Jerome
On Sun, May 20, 2012 at 12:40 AM, Niels Mayer <nielsmayer(a)gmail.com> wrote:
For a truly responsive skin, might be interesting to
consider some
design alternatives to the traditional -- such as "windows metro" :
http://en.wikipedia.org/wiki/Metro_(design_language)
One could, for example, use the notion of partially clipped text on
the left and right sides of the page to indicate that the mobile
screen could be swiped left or right, thereby exposing parts of the UI
that couldn't fit on a small screen. This could be used to hint at
presence of left/right side-bar content of a normal XWiki page, even
when displayed on a small screen.
Alternatley, the technique could also be used to break up a
traditional wiki document of linear sections, into a "metro style
panel" of horizontal pages. So in order to read within the section,
you'd swipe downward till you hit bottom of the section. But there'd
be a hint of the section header following and preceding to the right
and left. To go to the new section of a document, you'd therefore
sweep rightward; to go to previous you'd sweep left.
The following document talks about going from "website to metro-styled
app" but the same concept could be used to use a skin to transform
existing Wiki/Website layout to a mobile-friendly metro-styled design:
http://msdn.microsoft.com/en-us/library/windows/apps/hh868264.aspx
Some examples:
http://conversations.nokia.com/
http://justinangel.net/
http://justinangel.net/Windows8MetroBlog
http://css.dzone.com/articles/html5css3javascript-framework
http://www.behance.net/gallery/Metro-Style-Website-Template/3281283
http://theinspirationroom.com/daily/2011/microsoft-research-20-years/
-- Niels
http://www.nielsmayer.com
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
10:47 p.m.
New subject: [xwiki-devs] [GSoC] Responsive Skin
On Thu, May 17, 2012 at 5:57 PM, Jonathan Solichin <jssolichin(a)gmail.com> wrote:
Quick remarks :
- I like the toolbar on the right
- The top menu/navigation is wrong IMO (c.f. Desktop4) Why not forget
about it and integrate its feature with the tools on the right ? (just
a suggestion)
- IMO you don't have to have "everything" on mobile. There are actions
that does not make much sense doing on a mobile, like print preview,
etc. "Responsive" or "Adaptive" should also be interpreted in terms
of
feature I think. What do you think ?
- What's the purpose of the combo boxes on your mobile design ? If
it's navigation, it's wrong, it won't scale with a lot of entries.
- You're missing the search box which I think is very central. I'd go
as far as saying the search box should be the one stop shop for
navigation when you're on a mobile.
Hello friends
New quick mock up at the very end.
OK thanks for the explanation. You're right there will be quite a lot
of testing needed ; though testing should be done as much as possible
at development time, and not pushed back to till the end.
Side note to say I can provide testing on an HTC desire HT and iphone.
For mobiles, I think we need to test at least on WebKit and opera mini
on the devices we have (and IE if we can get hold on a windows phone).
For desktops, the usual bag.
The main problem with this proposal is that you
don't consider and maybe
you are not aware of XWiki's states and that the content in a wiki is
mostly dynamic:
The main problem with this proposal is that you don't consider and maybe
you are not aware of XWiki's states and that
the content in a wiki is
mostly dynamic:
- logged-in vs. logged-out content: The menus have many entries and the
way
you represented them does not scale. Check out the menus structure
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActionMenuProposal…
was the initial proposal, but some menu entries have changed since
then, but the mockups are ok to give you the impression of the entries).
This is true, I knew the mock up had a lot of static element that would
need some more thinking to make it dynamic. I just wanted to get a feel for
this kind of skin since I still wasn't sure how much creativity I
had--thought I have that answered now ahaha.
- empty vs. populated entries: This concerns 'Tags' and 'Comments'
section.
You're put 'Tags' and the
'Welcome' message on the same level because they
both have 3 rows of content, but this is not the case when 'Tags' are used
and populated (you will not have this consistency any more). When you are
logged-in, the 'Comments' section has another structure and would be
interesting to see how you want to display a comment too. Also you've
removed the 'Activity Stream' which is an important part.
Have a look at
http://incubator.myxwiki.org/xwiki/bin/view/Main/WebHomewhich
shows a wiki instance used: there are lots of spaces, lots of
activity entries, some tags, some comments.
Thank you for this link! I had a copy of XWIKI installed, but there was
nothing in it, so it did not help much. (eg. activity streams and so forth)
There is a Forum view of the mails
http://dev.xwiki.org/xwiki/bin/view/Community/Forum but I don't find it
very useful. Alternatives to see the mailinglists:
http://dev.xwiki.org/xwiki/bin/view/Community/MailingLists#HForums
Thank you, this has been very helpful in seeing the thread, And yes, i need
to get used to it aha.
- I think you underestimate time for both design and implementation.
Remember that in addition to the work it
represents by itself, which
in my opinion is already underestimated, you will have to present it
and discuss it with the community, refine accordingly, etc. This takes
more time that you imagine.
An improvement would be instead of having
just the numbers to put 'Week x.x:' in your timeline.
Also please add the calendar week number as Caty
suggests so that we
have a better view of when things happen.
Yes, this is what I needed, I really was not sure at all how the timeline
was working out. Thank you. I haven't yet updated the timeline, because I
think I need to think on it a bit more, since it seems I have done a lot of
underestimation.
- I don't know what you exactly mean under
"typography check", but a
priori one week sounds way too much for this
- what do you mean by "bumper" ?
Typography check is to check the text, actually the whole skin, on multiple
devices since some superphones have screens that are close to desktop in
resolution (eg. gNEX). So It was more to check whether the skin is
translating well given this circumstance. I thought this might take
slightly longer because of the need to hunt down these phones to check.
Bumper is to make sure everything can still follow the timeline--sort
of--in case I underestimated (which I did a lot aha) - I think what you have as refinements in week 10
"color variations,
inverse for night time" etc. you can just forget about that. That's
not really important, and it's not likely we can go this far during
the time of the GSoC.
Ok. Thank you for the info.
How much creativity ? A lot :) As much as you can afford !
While there are some good ideas in your skin
proposal, to be honest it
still does feel too much as "dressing up [the] product with a
last-minute garment" as Dieter Rams put it in this great text "Good
Design As A Key Business Advantage" [1].
What we want you to do is to take ownership of the product. Caty is
definitely right when she says you don't consider enough how XWiki
works. You should download XWiki on your computer, install it, plays
with it, get to know its feature, its *purpose*, and then start afresh
on a white (I mean transparent) sheet.
Right now your design has "colibri" written all over it. We can tell
from the links at the top and from the block in the footer. We can
tell from the way you've placed the "annotations" feature, etc. you
get the point. I hope you can make it as if you would never had seen
colibri.
Ok sorry, still testing out the waters. I thought the last proposal was
crazy enough--oops. And getting rid of Colibri in my head is harder than I
thought! As afforementioned I do have XWIKI installed, but it is pretty
barren and I still haven't gotten used to it. Caty's (should I be calling
her that) link with a populated XWIKI will help me with this. Also still
need to finish building from sources as well (doing that on ubuntu to pull
from git, but i'm new to that as well).
In any regards, here is another iteration, quick un-complete mock up
(Content space is white for now, just demoing menu/layout idea) since I
just fleshed some of the ideas in my head and haven't had the time to
completely flesh it out. I was wondering what you guys were thinking of it
though, before I invest more time.
http://jssolichin.com/public/3/desktop.jpg
http://jssolichin.com/public/3/desktop2.jpg
http://jssolichin.com/public/3/desktop3.jpg
http://jssolichin.com/public/3/desktop4.jpg
http://jssolichin.com/public/3/mobille.jpg
http://jssolichin.com/public/3/mobille2.jpg
http://jssolichin.com/public/3/mobille2.jpg<http://jssolichin.com/public…
This design divides navigation into 3, corresponding with borders. As the
user hovers nears the edge, it would reveal the whole link/more info. The
overflowed text serves to give them the idea there is more. By putting the
navigation in the borders, it becomes more static in a way--that is on each
new page, the "navigation links" placement will always be the same area.
Also, by detaching the links from the content, its size has more
flexibility allowing it to be bigger without interrupting the flow of
text-- allowing for bigger size clickable area.
In the mobile version, instead of hovering, the user would click. So it's a
bit similar to the Mobile Patterns[1] link Caty sent a while back since it
is like a sidebar to be revealed kind of thing.
Furthermore, this skin will really put the content front and center. And
again, this mockup is incomplete, i just wanted to give you a heads up on
this current exploration and was wondering your thoughts.
Again sorry, I'm still trying to get used to everything. Thank you for all
the inputs. I hope to be able to ramp up communication once school is
out--nearing critical point atm so a little bit busy.
OK cool. Thanks for the update, and looking forward for more.
I'll try to be available on IRC as much as possible if you want more
ping-pong interactions.
Cheers,
Jerome
Thanks all!,
Jonathan Solichin
[1] http://mobile-patterns.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
22 May
22 May
4:13 a.m.
New subject: [xwiki-devs] [GSoC] Responsive Skin
Hello friends!
This kind of progressive disclosure mechanism that you've used for the
Desktop version is good for the mobile versions, when the space is
limited.
But on desktops I think is gonna be very disruptive for the user to
hide/show such large portions of UI, especially on hover events (which
can
be triggered by accident). On desktop you have lots of space to use and
the
navigation/tools elements should be visible and accessible. So your
desktop
version would work better as a mobile version, but on landscape.
Yea, I was debating that as well. Maybe a delayed response would serve
better, or would the community rather have everything visible all the time?
On the 'content is the king' note, I just
wanted to state that XWiki is
an
application wiki. So you need to have in mind that 'content' means not
just
text, but application content: forms, links, text, attachments, etc. The
'content' thing is the hard part in representing it in a responsive
manner.
Thank you for the link, it will definitely help when fleshing out the
content.
For a truly responsive skin, might be interesting to
consider some
design alternatives to the traditional -- such as "windows metro" :
http://en.wikipedia.org/wiki/Metro_(design_language)
Interestingly, that was the original inspiration for the project. That's why
you have all those hidden mouse over events aha. It also takes some aspect
of the charm bar as well (from windows 8)--where all the page navigation
buttons are on the right. Also the huge fonts aha.
Alternatley, the technique could also be used to break
up a
traditional wiki document of linear sections, into a "metro style
panel" of horizontal pages. So in order to read within the section,
you'd swipe downward till you hit bottom of the section. But there'd
be a hint of the section header following and preceding to the right
and left. To go to the new section of a document, you'd therefore
sweep rightward; to go to previous you'd sweep left.
I thought this was a great solution for mobile where gestures can be made.
However, I think in a traditional desktop/mouse combo this would become an
issue since if we account for the lowest common denominator (no do
everything mouse), only one method of navigation is available--the scroll
wheel. This means that only up and down or left to right can be chosen. I do
agree that it is a very unique problem solution that they came up with
though. If you have any idea on how to go about the limitation of the scroll
wheel, i'd be interested!
The following document talks about going from
"website to metro-styled
app" but the same concept could be used to use a skin to transform
existing Wiki/Website layout to a mobile-friendly metro-styled design:
http://msdn.microsoft.com/en-us/library/windows/apps/hh868264.aspx
Thank you for all the links, they are definitely very insightful. On a side
note, I do like the explorations microsoft is doing (using windows phone
myself atm).
For mobiles, I think we need to test at least on
WebKit and opera mini
on the devices we have (and IE if we can get hold on a windows phone).
For desktops, the usual bag.
Yes, i think opera mini (with its limitation) is a good starting point. And
webkit because of its pervasiveness. I do have a windows phone to test--this
is the one that i'm worried about the most since they do some weird
proprietary stuff. For example, fonts are changed by the browser itself to
make it readable (i think) and some scripts do not work (even those that
work on desktop ie).
- The top menu/navigation is wrong IMO (c.f. Desktop4)
Why not forget
about it and integrate its feature with the tools on the right ? (just
a suggestion)
Originally I wanted to separate the two because the top navigation is a
"global" navigation and serves as a bread crumb, where as the right is more
page specific navigation. Do you think this is irrelevant? I will take this
into account, and think about how to best integrate the two if any.
- IMO you don't have to have
"everything" on mobile. There are actions
that does not make much sense doing on a mobile, like print preview,
etc. "Responsive" or "Adaptive" should also be interpreted in terms
of
feature I think. What do you think ?
BTW the GSoC title says "Responsive skin" ; but in terms of
implementation I have nothing against what LukeW calls "RESS"
(http://www.lukew.com/ff/entry.asp?1392) which basically says it's OK
to have some part of templates be device specific.
I briefly touched upon this, iirc, in the proposal (not the RESS
implementation specifically). You are right, some actions like print
are unnecessary for mobile. In this specific instance, I should have used
the more open term "export" for that oops. But in any regards, i myself am
not very sure of how much should be specifically hidden and its value. Since
unless we use RESS, the browser already have downloaded the files, it serves
no advantage for data reasons or other to hide something downloaded. It
might clean things up, but it doesn't add much beyond that. I was attempting
to try and give the "full experience" as much as possible (unless it does
hinder the experience). I know in most circumstance printing would not be
available, but who knows someone out there may be able to (eg. google cloud
print) and I don't want them to feel like this is a gimped down version of
XWIKI. But I definitely do see your point, what does the community think
about this?
- What's the purpose of the combo boxes on your
mobile design ? If
it's navigation, it's wrong, it won't scale with a lot of entries.
I'm not exactly sure what you mean by combo boxes? If it's the drop down, it
is to natively use the drop down chooser available on mobile devices to
allow for more finger friendly interaction. implementation [1], examples [2]
[3].
- You're missing the search box which I think is
very central. I'd go
as far as saying the search box should be the one stop shop for
navigation when you're on a mobile.
oops, i forgot about this. I am now making a check list of things needed to
make sure this doesn't happen again.
Finally, a revised timeline [4]. What does the community think?
Thanks all! Such a learning experience, thanks again for having me. Let me
know if there's anything I should improve on as a community member.
Jonathan Solichin
[1] http://css-tricks.com/convert-menu-to-dropdown/
[2] http://open.blogs.nytimes.com/tag/ipad/
[3] http://qph.cf.quoracdn.net/main-qimg-047773f000eeb9037febd55aff32d10c
[4] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin
--
View this message in context:
http://xwiki.475771.n2.nabble.com/GSoC-Responsive-Skin-tp7526728p7570269.ht…
Sent from the XWiki- Dev mailing list archive at Nabble.com.
4597
days inactive
4602
days old
5 comments
5 participants
participants (5)
-
Ecaterina Moraru (Valica) -
Jerome Velociter -
Jonathan Solichin -
jssolichin
-
Niels Mayer