Hi Jonathan,
On Sun, May 6, 2012 at 12:07 AM, Jonathan Solichin <jssolichin(a)gmail.com> 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/