Re: [xwiki-devs] [GSoC] Responsive Skin
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
Hi Jonathan, On Sun, May 6, 2012 at 12:07 AM, Jonathan Solichin <[email protected]> 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.
[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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/
Hi, On Tue, May 8, 2012 at 7:41 PM, Jerome Velociter <[email protected]>wrote:
Hi Jonathan,
On Sun, May 6, 2012 at 12:07 AM, Jonathan Solichin <[email protected]> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hello friends, The striped background is a bit distracting, something less prominent
would be better. But I guess that's just a filler.
I'm trying to figure out a simple non intensive background that would be unique. I think you might be right, the current one might be distracting. Though at the same time, it might also be some compression/size issue, since it's dots not stripes. But in any regards, I will look for a better solution. I think a unique font would be fine, as long as its license is compatible
with XWiki and that there are good fallback when no support is available for @font-face.
Right. Is there a suggested font that xwiki uses that i am not aware of? beside the one used in colibri
Also in addition to pure content, your page is missing a breadcrumb
Do you think it would make sense if it continues the global nav links currently at the top of the page? or would it be better within the pure content? What I would like you to do now is to incorporate wiki content in your
design. I think this will also help for typographic choices.
Right. I am sorry for my absence and lack of update. I have been swamped with school. This is my last week so finals and several 10+ page essays are due. I will be much more active in the coming week. i hope you understand. Thanks again everyone!
participants (3)
-
Ecaterina Moraru (Valica) -
Jerome Velociter -
Jonathan Solichin