[GSoC] Responsive Skin

classic Classic list List threaded Threaded
48 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[GSoC] Responsive Skin

Jerome Velociter-4
Hi Jonathan, everybody,

As you may know the "Responsive Skin" project has been accepted for
the GSoC 2012. I will be mentoring the project, together with
Ecaterina and everyone that wants to get involved. Jonathan Solichin
is the student who will realize the project.

Jonathan, I'd like you start telling us about your plans and an
expected timeline proposal for the realization of the project.

Then the next step is to create a page on the design page in the
development wiki [1] and start the work here.

I'll lay here some of my thoughts on the project, and what I
personally consider conditions for success (for the moment) :
* I'd like we start with a phase of "paper" design (I mean with gimp
or photoshop or whatever tool to produce images).
* I think we should limit the feature set of the skin ; not trying to
do everything right away (there are potentially a lot of features to
work on, from livetables to data editors, to applications, etc.)
* For a start, focus should be given on content and navigation. With a
mobile-first approach, expanding up to large-screens desktop.
* I think it's OK to have semantic break points (like "phone",
"tablet", etc.) as long as the skin is actually responsive and adapt
to whatever real estate is available. We should be able to "drag the
corner" of a browser window and have the skin display well at all
sizes.

Of course all those points are open for discussion, those are just my
views on the topic. Feedback from the community welcomed.

Jonathan, looking forward hearing from you,

Cheers,
Jerome

[1] http://dev.xwiki.org/xwiki/bin/view/Design/WebHome
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

jssolichin
Hi Jerome & Community,

Here is the design page for the Responsive Skin [1].

* I'd like we start with a phase of "paper" design (I mean with gimp
> or photoshop or whatever tool to produce images).


This is available in the design page, or, alternatively phone [2], tablet
[3], desktop [4]

* I think we should limit the feature set of the skin ; not trying to
> do everything right away (there are potentially a lot of features to
> work on, from livetables to data editors, to applications, etc.)

* For a start, focus should be given on content and navigation. With a
> mobile-first approach, expanding up to large-screens desktop.

* I think it's OK to have semantic break points (like "phone",
> "tablet", etc.) as long as the skin is actually responsive and adapt
> to whatever real estate is available. We should be able to "drag the
> corner" of a browser window and have the skin display well at all
> sizes.


Agreed.

Also, current questions (c&p) from other e-mail regarding gsoc:

1. Specific support for non-javascript capable browser? I feel like it is
not necessarily since browser which can not support javascript will fall
back by itself. More over, it would not be capable of carrying out
media-queries required for responsive design and some XWIKI features (such
as live tables?) anyway.
2. Is the community ok with trying to use "true (html)" drop downs / forms
in order to fully utilize functions built in to phone/tablets [5]?
3. Pressable Links: should they be bigger on mobile to help facilitate
touching on words, or would it be better to use a "background" to create a
"touch area"? Both are in the phone mock up [6]. Former demonstrated in
quicklinks, latter in the "Spaces" section.


[1] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin
[2] http://jssolichin.com/public/mobile.jpg
[3] http://jssolichin.com/public/tablet.jpg
[4] http://jssolichin.com/public/desktop.jpg
[5] http://css-tricks.com/convert-menu-to-dropdown/
[6] http://jssolichin.com/public/mobile.jpg
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Jerome Velociter-4
Hi Jonathan,

On Sun, May 6, 2012 at 12:07 AM, Jonathan Solichin <[hidden email]> wrote:
> Hi Jerome & Community,
>
> Here is the design page for the Responsive Skin [1].

OK.

About the tentative time-line, please confront each step with a date.

About the mock-ups, personally I would prefer we make it a complete
initial phase of the project, to take the time to create a skin
afresh, trying as much as possible to forget about what has been done
in colibri (the current default skin of XWiki) and instead think
outside the box. This would mean forgetting about how menus, links,
information etc. is displayed, and come up with an actual new skin.
Especially since I understand you have design skills ;)
I'm curious what other members of the community think about going this
way, any opinion more than welcomed.

See below for your additional questions.

>
> * I'd like we start with a phase of "paper" design (I mean with gimp
>> or photoshop or whatever tool to produce images).
>
>
> This is available in the design page, or, alternatively phone [2], tablet
> [3], desktop [4]
>
> * I think we should limit the feature set of the skin ; not trying to
>> do everything right away (there are potentially a lot of features to
>> work on, from livetables to data editors, to applications, etc.)
>
> * For a start, focus should be given on content and navigation. With a
>> mobile-first approach, expanding up to large-screens desktop.
>
> * I think it's OK to have semantic break points (like "phone",
>> "tablet", etc.) as long as the skin is actually responsive and adapt
>> to whatever real estate is available. We should be able to "drag the
>> corner" of a browser window and have the skin display well at all
>> sizes.
>
>
> Agreed.
>
> Also, current questions (c&p) from other e-mail regarding gsoc:
>
> 1. Specific support for non-javascript capable browser? I feel like it is
> not necessarily since browser which can not support javascript will fall
> back by itself. More over, it would not be capable of carrying out
> media-queries required for responsive design and some XWIKI features (such
> as live tables?) anyway.

At least content should display, links be accessible etc.

> 2. Is the community ok with trying to use "true (html)" drop downs / forms
> in order to fully utilize functions built in to phone/tablets [5]?

When it makes sense, yes. Note that an approach could be to inject
drop downs in JS for certain media queries.

> 3. Pressable Links: should they be bigger on mobile to help facilitate
> touching on words, or would it be better to use a "background" to create a
> "touch area"? Both are in the phone mock up [6]. Former demonstrated in
> quicklinks, latter in the "Spaces" section.

Makes sense.

Jerome.



--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Ecaterina Moraru (Valica)
Hi,

On Tue, May 8, 2012 at 7:41 PM, Jerome Velociter <[hidden email]>wrote:

> Hi Jonathan,
>
> On Sun, May 6, 2012 at 12:07 AM, Jonathan Solichin <[hidden email]>
> wrote:
> > Hi Jerome & Community,
> >
> > Here is the design page for the Responsive Skin [1].
>
> OK.
>
> About the tentative time-line, please confront each step with a date.
>
> About the mock-ups, personally I would prefer we make it a complete
> initial phase of the project, to take the time to create a skin
> afresh, trying as much as possible to forget about what has been done
> in colibri (the current default skin of XWiki) and instead think
> outside the box. This would mean forgetting about how menus, links,
> information etc. is displayed, and come up with an actual new skin.
> Especially since I understand you have design skills ;)
> I'm curious what other members of the community think about going this
> way, any opinion more than welcomed.
>

I would love to see some fresh ideas of how the responsive skin would look
like.
Jonathan should provide some a timeline in order to see how expensive this
phase would be.

Please also take a look at other ideas/layouts for the mobile skin
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileSkin


>
> See below for your additional questions.
>
> >
> > * I'd like we start with a phase of "paper" design (I mean with gimp
> >> or photoshop or whatever tool to produce images).
> >
> >
> > This is available in the design page, or, alternatively phone [2], tablet
> > [3], desktop [4]
> >
> > * I think we should limit the feature set of the skin ; not trying to
> >> do everything right away (there are potentially a lot of features to
> >> work on, from livetables to data editors, to applications, etc.)
> >
> > * For a start, focus should be given on content and navigation. With a
> >> mobile-first approach, expanding up to large-screens desktop.
> >
> > * I think it's OK to have semantic break points (like "phone",
> >> "tablet", etc.) as long as the skin is actually responsive and adapt
> >> to whatever real estate is available. We should be able to "drag the
> >> corner" of a browser window and have the skin display well at all
> >> sizes.
> >
> >
> > Agreed.
> >
> > Also, current questions (c&p) from other e-mail regarding gsoc:
> >
> > 1. Specific support for non-javascript capable browser? I feel like it is
> > not necessarily since browser which can not support javascript will fall
> > back by itself. More over, it would not be capable of carrying out
> > media-queries required for responsive design and some XWIKI features
> (such
> > as live tables?) anyway.
>
>
XWiki usually has support for its features when the javascript is disabled.

Thanks,
Caty


>  At least content should display, links be accessible etc.
>
> > 2. Is the community ok with trying to use "true (html)" drop downs /
> forms
> > in order to fully utilize functions built in to phone/tablets [5]?
>
> When it makes sense, yes. Note that an approach could be to inject
> drop downs in JS for certain media queries.
>
> > 3. Pressable Links: should they be bigger on mobile to help facilitate
> > touching on words, or would it be better to use a "background" to create
> a
> > "touch area"? Both are in the phone mock up [6]. Former demonstrated in
> > quicklinks, latter in the "Spaces" section.
>
> Makes sense.
>
> Jerome.
>
> >
> >
> > [1] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin
> > [2] http://jssolichin.com/public/mobile.jpg
> > [3] http://jssolichin.com/public/tablet.jpg
> > [4] http://jssolichin.com/public/desktop.jpg
> > [5] http://css-tricks.com/convert-menu-to-dropdown/
> > [6] http://jssolichin.com/public/mobile.jpg
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Jérôme Velociter
> Winesquare
> http://www.winesquare.net/
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

jssolichin
In reply to this post by Jerome Velociter-4
Hello friends,

First thank you for the inputs.

> About the tentative time-line, please confront each step with a date.

I'm not sure whether it was unclear or not, but the numbers represents the
weeks of GSOC and are not arbritrary. Unless you want the exact date, then
I can go ahead and revise it again. I also appended to the beginning: a
design exploration stage as per your request. [1]

> About the mock-ups, personally I would prefer we make it a complete
> > initial phase of the project, to take the time to create a skin
> > afresh, trying as much as possible to forget about what has been done
> > in colibri (the current default skin of XWiki) and instead think
> > outside the box. This would mean forgetting about how menus, links,
> > information etc. is displayed, and come up with an actual new skin.
> > Especially since I understand you have design skills ;)

Thank you. Right, ok so I wasn't sure how much creativity i am allowed with
the skin and that's why my first mock up is pretty close to colibri. I
created a second mock up of a more "brave" skin. desktop [2], mobile [3],
What does the community think? wrong or right direction?


> I would love to see some fresh ideas of how the responsive skin would look
> like.
> Jonathan should provide some a timeline in order to see how expensive this
> phase would be.

Ok so at the moment, I am aiming for a week of design exploration. But to
be honest, I have never worked on a project like this, or created a time
line. If someone could comment on my timeline [1] as to whether it is
totally skewed or just about right, that would be great.

Please also take a look at other ideas/layouts for the mobile skin
> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileSkin

This is a great resource. I will definitely look into this more deeply.
Thank you!

On a non Responsive Skin topic, is there a place where I can read/reply to
the mailing list, beside email, that is more dedicated (like how google
groups have an online "viewer")? Like the way links are delineated at the
bottom as footnotes, does everyone do that manually, or is there a
dedicated place that does this for you? It is a little bit confusing to
read emails with multi-level quotes. Or maybe I am just not used to it.
Thanks in advance.

Kind Regards,
Jonathan Solichin

[1] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin
[2] http://jssolichin.com/public/2/desktop.jpg
[3] http://jssolichin.com/public/2/mobile.jpg
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Ecaterina Moraru (Valica)
Hi Jonathan,

On Sat, May 12, 2012 at 1:33 PM, Jonathan Solichin <[hidden email]>wrote:

> Hello friends,
>
> First thank you for the inputs.
>
> > About the tentative time-line, please confront each step with a date.
>
> I'm not sure whether it was unclear or not, but the numbers represents the
> weeks of GSOC and are not arbritrary. Unless you want the exact date, then
> I can go ahead and revise it again. I also appended to the beginning: a
> design exploration stage as per your request. [1]
>

Yes, it was not clear at all :) An improvement would be instead of having
just the numbers to put 'Week x.x:' in your timeline.


>
> > About the mock-ups, personally I would prefer we make it a complete
> > > initial phase of the project, to take the time to create a skin
> > > afresh, trying as much as possible to forget about what has been done
> > > in colibri (the current default skin of XWiki) and instead think
> > > outside the box. This would mean forgetting about how menus, links,
> > > information etc. is displayed, and come up with an actual new skin.
> > > Especially since I understand you have design skills ;)
>
> Thank you. Right, ok so I wasn't sure how much creativity i am allowed with
> the skin and that's why my first mock up is pretty close to colibri. I
> created a second mock up of a more "brave" skin. desktop [2], mobile [3],
> What does the community think? wrong or right direction?
>

The desktop mockup is interesting. I like the left 'application' navigation
(Quick Links positioning) . Also the Wiki>Space>Page navigation is real
nice and the way you represented the menu-submenu entries (Export and More).

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/ActionMenuProposal2(this
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).

- 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.

- static vs. dynamic content: In a wiki you have 'static' content (content
generated by XWiki: like labels, instructions, buttons, etc. This is static
because can't be changed by user, but still keep in mind that XWiki can be
internationalized, so the dimension is still kind of dynamic) and 'dynamic'
content (content generated by user: titles, text, images, comments, tags,
etc.). Right now in your mockup you assume that some design elements are
gonna have the same dimension and this is not true. And the most striking
case is the page title: 'Web Home'. On other pages different than the
space's WebHomes, that title can be as long as the user wants: 'Responsive
Skin', etc.

Scalability is important when doing a proposal, especially in the
Responsive area, where the layout needs to be flexible also for multiple
devices.


>
> > I would love to see some fresh ideas of how the responsive skin would
> look
> > like.
> > Jonathan should provide some a timeline in order to see how expensive
> this
> > phase would be.
>
> Ok so at the moment, I am aiming for a week of design exploration. But to
> be honest, I have never worked on a project like this, or created a time
> line. If someone could comment on my timeline [1] as to whether it is
> totally skewed or just about right, that would be great.
>
> Please also take a look at other ideas/layouts for the mobile skin
> > http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileSkin
>
> This is a great resource. I will definitely look into this more deeply.
> Thank you!
>
> On a non Responsive Skin topic, is there a place where I can read/reply to
> the mailing list, beside email, that is more dedicated (like how google
> groups have an online "viewer")?


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


> Like the way links are delineated at the
> bottom as footnotes, does everyone do that manually, or is there a
> dedicated place that does this for you?


This is done manually. Some users like to have all the links at the bottom,
some (like me) put them in the context.


> It is a little bit confusing to
> read emails with multi-level quotes. Or maybe I am just not used to it.
>

I guess you will have to get use to it :) The quotes are great for context
in order to know what was said before this and keep all the content inside
one mail and not needing to search it in other threads.

Thanks,
Caty


> Thanks in advance.
>
> Kind Regards,
> Jonathan Solichin
>
> [1] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin
> [2] http://jssolichin.com/public/2/desktop.jpg
> [3] http://jssolichin.com/public/2/mobile.jpg
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Jerome Velociter-4
In reply to this post by jssolichin
Hi Jonathan,

On Sat, May 12, 2012 at 12:33 PM, Jonathan Solichin
<[hidden email]> wrote:

> Hello friends,
>
> First thank you for the inputs.
>
>> About the tentative time-line, please confront each step with a date.
>
> I'm not sure whether it was unclear or not, but the numbers represents the
> weeks of GSOC and are not arbritrary. Unless you want the exact date, then
> I can go ahead and revise it again. I also appended to the beginning: a
> design exploration stage as per your request. [1]

OK, I didn't understood that at first.

Couple of comments on the timeline :

- 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.
- 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" ?
- 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.

Also please add the calendar week number as Caty suggests so that we
have a better view of when things happen.

>> About the mock-ups, personally I would prefer we make it a complete
>> > initial phase of the project, to take the time to create a skin
>> > afresh, trying as much as possible to forget about what has been done
>> > in colibri (the current default skin of XWiki) and instead think
>> > outside the box. This would mean forgetting about how menus, links,
>> > information etc. is displayed, and come up with an actual new skin.
>> > Especially since I understand you have design skills ;)
>
> Thank you. Right, ok so I wasn't sure how much creativity i am allowed with
> the skin and that's why my first mock up is pretty close to colibri. I
> created a second mock up of a more "brave" skin. desktop [2], mobile [3],
> What does the community think? wrong or right direction?

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.

I want to emphasis on the fact that, at least for me, at the end of
the GSoC, the design you can come up with will likely have more value
than the code you can deliver. Don't get me wrong, I'm not saying you
shouldn't implement it ;) What I mean is that if you bring us a great
design and a working proof-of-concept implementation - that might not
be perfect - then we can certainly do something with that as a
community with quite some developers. It's more likely someone
interested will take over after you. While if the design feels flawed
to begin with, I think no matter how good the implementation is, it's
probably going to take the dust in the attic ;)

Hope that nourishes your reflexion, and looking forward your work.

Thanks
Jerome

[1] http://www.fastcodesign.com/1669725/dieter-rams-on-good-design-as-a-key-business-advantage

>
>
>> I would love to see some fresh ideas of how the responsive skin would look
>> like.
>> Jonathan should provide some a timeline in order to see how expensive this
>> phase would be.
>
> Ok so at the moment, I am aiming for a week of design exploration. But to
> be honest, I have never worked on a project like this, or created a time
> line. If someone could comment on my timeline [1] as to whether it is
> totally skewed or just about right, that would be great.
>
> Please also take a look at other ideas/layouts for the mobile skin
>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/MobileSkin
>
> This is a great resource. I will definitely look into this more deeply.
> Thank you!
>
> On a non Responsive Skin topic, is there a place where I can read/reply to
> the mailing list, beside email, that is more dedicated (like how google
> groups have an online "viewer")? Like the way links are delineated at the
> bottom as footnotes, does everyone do that manually, or is there a
> dedicated place that does this for you? It is a little bit confusing to
> read emails with multi-level quotes. Or maybe I am just not used to it.
> Thanks in advance.
>
> Kind Regards,
> Jonathan Solichin
>
> [1] http://dev.xwiki.org/xwiki/bin/view/Design/ResponsiveSkin
> [2] http://jssolichin.com/public/2/desktop.jpg
> [3] http://jssolichin.com/public/2/mobile.jpg
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

jssolichin
In reply to this post by Jerome Velociter-4
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/ActionMenuProposal2(this
> 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.

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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Ecaterina Moraru (Valica)
Hi,

On Thu, May 17, 2012 at 6:57 PM, Jonathan Solichin <[hidden email]>wrote:

> 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/ActionMenuProposal2(this
> > 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).
>

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-hsqldb/
Right now the latest version is 4.1-milestone-1.


>
> 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=1&l=30&s=doc.creationDate&d=desc&name=app

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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Niels Mayer
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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Jerome Velociter-4
In reply to this post by jssolichin
On Thu, May 17, 2012 at 5:57 PM, Jonathan Solichin <[hidden email]> wrote:

> 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/ActionMenuProposal2(this
>> 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)

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.

>
>
>> - 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>

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.

>
> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Jerome Velociter-4
In reply to this post by Niels Mayer
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 <[hidden email]> 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
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

jssolichin
In reply to this post by Jerome Velociter-4
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.
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
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

jssolichin
In reply to this post by Jerome Velociter-4
Hello Friends,

Here is a new set of mockup.

[] http://jssolichin.com/public/4/1.%20Home.png
[] http://jssolichin.com/public/4/2.%20Home-comm.png
[] http://jssolichin.com/public/4/3.%20Home-navhover.png

[] http://jssolichin.com/public/4/4.%20mobile.png
[] http://jssolichin.com/public/4/5.%20mobile-menu.png

What do you guys think? The idea is that the sidebar would be replicated,
but hidden in the mobile (except for the hint that it's there.

Everything non-content is combined. I think that if you are looking at the
comments/attachment/other sections, you are not thinking about navigating
away from the page so the nav section is not that needed. So this
consolidates/saves space. Let me know if this is the wrong mentality.

Thanks!
Jonathan Solichin
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Jerome Velociter-4
Hi Jonathan,

Great move going back to wire-framing essentials :)
I think you're on to something here. I like that approach : the fact
the search bar is always visible, and that the "content is king".

Two things :

* The way the navigation links are organized/grouped together is a bit
weird (the upper part with wiki/space/page links)
* On the desktop you probably don't want that inner scroller, but
rather have the right panel fixed and keep the page's natural scroll.

Let's wait for more feedback ; personally I'm very much in favor of
digging that direction.

Keep us posted

Jerome.

On Wed, May 23, 2012 at 11:47 PM, Jonathan Solichin
<[hidden email]> wrote:

> Hello Friends,
>
> Here is a new set of mockup.
>
> [] http://jssolichin.com/public/4/1.%20Home.png
> [] http://jssolichin.com/public/4/2.%20Home-comm.png
> [] http://jssolichin.com/public/4/3.%20Home-navhover.png
>
> [] http://jssolichin.com/public/4/4.%20mobile.png
> [] http://jssolichin.com/public/4/5.%20mobile-menu.png
>
> What do you guys think? The idea is that the sidebar would be replicated,
> but hidden in the mobile (except for the hint that it's there.
>
> Everything non-content is combined. I think that if you are looking at the
> comments/attachment/other sections, you are not thinking about navigating
> away from the page so the nav section is not that needed. So this
> consolidates/saves space. Let me know if this is the wrong mentality.
>
> Thanks!
> Jonathan Solichin
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Guillaume Lerouge
Hi,

I like this concept as well. The menu part still needs to be refined, but
it's an interesting way to look at the skin.

Putting the menu on the left would be more familiar to mobile users (the
nav menu is usually on the right in all the mobile apps I regularly use).

Jonathan: I don't remember whether Jérôme pointed you to his lyrebird work:
http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-cssbut
it could be an additional source of inspiration for you.

Guillaume

On Thu, May 24, 2012 at 12:49 AM, Jerome Velociter <[hidden email]>wrote:

> Hi Jonathan,
>
> Great move going back to wire-framing essentials :)
> I think you're on to something here. I like that approach : the fact
> the search bar is always visible, and that the "content is king".
>
> Two things :
>
> * The way the navigation links are organized/grouped together is a bit
> weird (the upper part with wiki/space/page links)
> * On the desktop you probably don't want that inner scroller, but
> rather have the right panel fixed and keep the page's natural scroll.
>
> Let's wait for more feedback ; personally I'm very much in favor of
> digging that direction.
>
> Keep us posted
>
> Jerome.
>
> On Wed, May 23, 2012 at 11:47 PM, Jonathan Solichin
> <[hidden email]> wrote:
> > Hello Friends,
> >
> > Here is a new set of mockup.
> >
> > [] http://jssolichin.com/public/4/1.%20Home.png
> > [] http://jssolichin.com/public/4/2.%20Home-comm.png
> > [] http://jssolichin.com/public/4/3.%20Home-navhover.png
> >
> > [] http://jssolichin.com/public/4/4.%20mobile.png
> > [] http://jssolichin.com/public/4/5.%20mobile-menu.png
> >
> > What do you guys think? The idea is that the sidebar would be replicated,
> > but hidden in the mobile (except for the hint that it's there.
> >
> > Everything non-content is combined. I think that if you are looking at
> the
> > comments/attachment/other sections, you are not thinking about navigating
> > away from the page so the nav section is not that needed. So this
> > consolidates/saves space. Let me know if this is the wrong mentality.
> >
> > Thanks!
> > Jonathan Solichin
> > _______________________________________________
> > devs mailing list
> > [hidden email]
> > http://lists.xwiki.org/mailman/listinfo/devs
>
>
>
> --
> Jérôme Velociter
> Winesquare
> http://www.winesquare.net/
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Jerome Velociter-4
On Thu, May 24, 2012 at 11:30 AM, Guillaume Lerouge <[hidden email]> wrote:
> Hi,
>
> I like this concept as well. The menu part still needs to be refined, but
> it's an interesting way to look at the skin.
>
> Putting the menu on the left would be more familiar to mobile users (the
> nav menu is usually on the right in all the mobile apps I regularly use).

Maybe we don't want to be like every other app ;p

I don't know, I think we can try it out on the right and see how it
feels. Same for the desktop in fact ; though I think it's going to
feel more natural on the right in that case.

>
> Jonathan: I don't remember whether Jérôme pointed you to his lyrebird work:
> http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-cssbut
> it could be an additional source of inspiration for you.

I don't remember I did.

Let me fix the link :
http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-css
Also, sources are on github : https://github.com/jvelo/Lyrebird

Jerome


>
> Guillaume
>
> On Thu, May 24, 2012 at 12:49 AM, Jerome Velociter <[hidden email]>wrote:
>
>> Hi Jonathan,
>>
>> Great move going back to wire-framing essentials :)
>> I think you're on to something here. I like that approach : the fact
>> the search bar is always visible, and that the "content is king".
>>
>> Two things :
>>
>> * The way the navigation links are organized/grouped together is a bit
>> weird (the upper part with wiki/space/page links)
>> * On the desktop you probably don't want that inner scroller, but
>> rather have the right panel fixed and keep the page's natural scroll.
>>
>> Let's wait for more feedback ; personally I'm very much in favor of
>> digging that direction.
>>
>> Keep us posted
>>
>> Jerome.
>>
>> On Wed, May 23, 2012 at 11:47 PM, Jonathan Solichin
>> <[hidden email]> wrote:
>> > Hello Friends,
>> >
>> > Here is a new set of mockup.
>> >
>> > [] http://jssolichin.com/public/4/1.%20Home.png
>> > [] http://jssolichin.com/public/4/2.%20Home-comm.png
>> > [] http://jssolichin.com/public/4/3.%20Home-navhover.png
>> >
>> > [] http://jssolichin.com/public/4/4.%20mobile.png
>> > [] http://jssolichin.com/public/4/5.%20mobile-menu.png
>> >
>> > What do you guys think? The idea is that the sidebar would be replicated,
>> > but hidden in the mobile (except for the hint that it's there.
>> >
>> > Everything non-content is combined. I think that if you are looking at
>> the
>> > comments/attachment/other sections, you are not thinking about navigating
>> > away from the page so the nav section is not that needed. So this
>> > consolidates/saves space. Let me know if this is the wrong mentality.
>> >
>> > Thanks!
>> > Jonathan Solichin
>> > _______________________________________________
>> > devs mailing list
>> > [hidden email]
>> > http://lists.xwiki.org/mailman/listinfo/devs
>>
>>
>>
>> --
>> Jérôme Velociter
>> Winesquare
>> http://www.winesquare.net/
>> _______________________________________________
>> devs mailing list
>> [hidden email]
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs



--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

jssolichin
In reply to this post by Jerome Velociter-4
Hello friends,

Thank you, glad to hear that I am getting somewhere

Here is a better version of the sidebar:
http://jssolichin.com/public/4/4.%20Home-alt.png

The boxes with the x will be icons. having those I think will help inform
the reader what is available, instead of the previous metro like overflow.
It will also allow a space for numbers showing how much content is
available in that section. When you hover over that section, it will still
reveal the hover nav in the last mock up to allow for easier clicking and
clarity (as to what the icons are):

http://jssolichin.com/public/4/3.%20Home-navhover.png

I know that the icons will not fit with longer section names like comments,
so the icon might be placed above the section name, or be smaller. On that
point, I would just like to mention that i'm hoping to also allow the
reader to resize the sidebar size fluidly. So if they are reading the
comments section, they can devote more space to it. This will, however, be
disabled in the mobile version.

* The way the navigation links are organized/grouped together is a bit
> weird (the upper part with wiki/space/page links)
>
Visually, I'm not sure if it came through in the wireframe, but i'm
imagining it like the iphone folder [1], where we have the breadcrumb/nav
(wiki/space/pages) always visible, then when the user clicks it, it reveals
the "watch page, access rights, etc." By iphone folder like i mean, it
pushes everything down and visually seems to reveal something underneath.
But that last point is trivial.

More technically, since the navigation is vertical, the breadcrumb style is
a bit unclear, and do need to be more refined. Right now  i'm thinking
maybe a folder esque structure:
x wiki
\_ x space
   \_x pages

but I feel like that might get to cluttered. Maybe we should just remove
the breadcrumb navigation and just have it like in the lyrebird where it
appears as part of the content and not as a "global nav?" What does the
community think?

 * On the desktop you probably don't want that inner scroller, but
> rather have the right panel fixed and keep the page's natural scroll.

You're right, that would make sense. I think the right solution would be to
make the right sidebar scroll like the chatlist window on facebook where if
you hover over the area, it will reveal a scroll bar indicator to show your
vertical location and allow you to scroll that section using the mouse
wheel.

Do you guys think it will be ok that we do not have the up and down arrow?
or would that be bad usability. I personally think it will be fine since
even sites like gmail uses a non native scroll indicator without the up and
down arrow--it's just prettier.

 The menu part still needs to be refined

 Did I address it earlier in this email, or am I still missing something?
Can you clarify specifically which point for me to work at?

> Putting the menu on the left would be more familiar to mobile users (the
> > nav menu is usually on the right in all the mobile apps I regularly
> use).
> Maybe we don't want to be like every other app ;p
> I don't know, I think we can try it out on the right and see how it
> feels. Same for the desktop in fact ; though I think it's going to
> feel more natural on the right in that case.

 I think both points are valid. I personally chose the right side because I
feel like when you land on a page, you want to read content first. But I do
know what you mean, left is the traditional side and is used in giant sites
like gmail, facebook, hotmail and so forth. I think we should get more
input on this.

> Jonathan: I don't remember whether Jérôme pointed you to his lyrebird
> work:
> >
> http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-cssbut
> > it could be an additional source of inspiration for you.
> I don't remember I did.
> Let me fix the link :
>
> http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-css
> Also, sources are on github : https://github.com/jvelo/Lyrebird<https://github.com/jvelo/Lyrebird;cid=1338111304826-974>

Thank you, this will be a wonderful resource!

Let me know what you guys think.

Best,
Jonathan Solichin

[1] http://media.tecca.com/2011/02/17/mh-630-iphone-folder-header-630w.jpg
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

Jerome Velociter-4
On Sun, May 27, 2012 at 12:06 PM, Jonathan Solichin <[hidden email]>wrote:

> Hello friends,
>
> Thank you, glad to hear that I am getting somewhere
>
> Here is a better version of the sidebar:
> http://jssolichin.com/public/4/4.%20Home-alt.png
>
> The boxes with the x will be icons. having those I think will help inform
> the reader what is available, instead of the previous metro like overflow.
> It will also allow a space for numbers showing how much content is
> available in that section. When you hover over that section, it will still
> reveal the hover nav in the last mock up to allow for easier clicking and
> clarity (as to what the icons are):
>
> http://jssolichin.com/public/4/3.%20Home-navhover.png
>
> I know that the icons will not fit with longer section names like comments,
> so the icon might be placed above the section name, or be smaller. On that
> point, I would just like to mention that i'm hoping to also allow the
> reader to resize the sidebar size fluidly. So if they are reading the
> comments section, they can devote more space to it. This will, however, be
> disabled in the mobile version.
>
> * The way the navigation links are organized/grouped together is a bit
> > weird (the upper part with wiki/space/page links)
> >
> Visually, I'm not sure if it came through in the wireframe, but i'm
> imagining it like the iphone folder [1], where we have the breadcrumb/nav
> (wiki/space/pages) always visible, then when the user clicks it, it reveals
> the "watch page, access rights, etc." By iphone folder like i mean, it
> pushes everything down and visually seems to reveal something underneath.
> But that last point is trivial.
>
> More technically, since the navigation is vertical, the breadcrumb style is
> a bit unclear, and do need to be more refined. Right now  i'm thinking
> maybe a folder esque structure:
> x wiki
> \_ x space
>   \_x pages
>
> but I feel like that might get to cluttered. Maybe we should just remove
> the breadcrumb navigation and just have it like in the lyrebird where it
> appears as part of the content and not as a "global nav?" What does the
> community think?
>
>  * On the desktop you probably don't want that inner scroller, but
> > rather have the right panel fixed and keep the page's natural scroll.
>
> You're right, that would make sense. I think the right solution would be to
> make the right sidebar scroll like the chatlist window on facebook where if
> you hover over the area, it will reveal a scroll bar indicator to show your
> vertical location and allow you to scroll that section using the mouse
> wheel.
>
> Do you guys think it will be ok that we do not have the up and down arrow?
> or would that be bad usability. I personally think it will be fine since
> even sites like gmail uses a non native scroll indicator without the up and
> down arrow--it's just prettier.
>


I don't have any issue with a JS scroller to make it beautiful, as long as
it preserve native behavior (keyboard, etc.) and that it degrades nicely
when JS is not present.

Jerome



>
>  The menu part still needs to be refined
>
>  Did I address it earlier in this email, or am I still missing something?
> Can you clarify specifically which point for me to work at?
>
> > Putting the menu on the left would be more familiar to mobile users (the
> > > nav menu is usually on the right in all the mobile apps I regularly
> > use).
> > Maybe we don't want to be like every other app ;p
> > I don't know, I think we can try it out on the right and see how it
> > feels. Same for the desktop in fact ; though I think it's going to
> > feel more natural on the right in that case.
>
>  I think both points are valid. I personally chose the right side because I
> feel like when you land on a page, you want to read content first. But I do
> know what you mean, left is the traditional side and is used in giant sites
> like gmail, facebook, hotmail and so forth. I think we should get more
> input on this.
>
> > Jonathan: I don't remember whether Jérôme pointed you to his lyrebird
> > work:
> > >
> >
> http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-cssbut
> > > it could be an additional source of inspiration for you.
> > I don't remember I did.
> > Let me fix the link :
> >
> >
> http://www.velociter.fr/journal/lyrebird-a-xwiki-skin-based-on-bootstrap-css
> > Also, sources are on github : https://github.com/jvelo/Lyrebird<
> https://github.com/jvelo/Lyrebird;cid=1338111304826-974>
>
> Thank you, this will be a wonderful resource!
>
> Let me know what you guys think.
>
> Best,
> Jonathan Solichin
>
> [1] http://media.tecca.com/2011/02/17/mh-630-iphone-folder-header-630w.jpg
> _______________________________________________
> devs mailing list
> [hidden email]
> http://lists.xwiki.org/mailman/listinfo/devs
>



--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: [GSoC] Responsive Skin

jssolichin
In reply to this post by Jerome Velociter-4
Hello friends,

So here is a clearer illustration of what I am aiming for:

http://sdrv.ms/LO70JI

The font being used in these design is Arial (with changes to make it more
unique). I was wondering whether the community would like a more regular
looking font, or a bolder and unique one?

I would be glad to hear the community's feedback. I tried to bring into
account all the comments, but let me know if I missed something.

Thanks again,
Jonathan Solichin

p,s almost done with school (one week), will be able to push faster and
better soon. Sorry about that!
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
123