Hi,
On Thu, May 17, 2012 at 6:57 PM, Jonathan Solichin <jssolichin(a)gmail.com>wrote;wrote:
Hello friends
New quick mock up at the very end.
The main problem with this proposal is that you
don't consider and maybe
you are not aware of XWiki's states and that the content in a wiki is
mostly dynamic:
The main problem with this proposal is that you don't consider and maybe
you are not aware of XWiki's states and that
the content in a wiki is
mostly dynamic:
- logged-in vs. logged-out content: The menus have many entries and the
way
you represented them does not scale. Check out the menus structure
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/ActionMenuProposal…
was the initial proposal, but some menu entries
have changed since
then, but the mockups are ok to give you the impression of the entries).
This is true, I knew the mock up had a lot of static element that would
need some more thinking to make it dynamic. I just wanted to get a feel for
this kind of skin since I still wasn't sure how much creativity I
had--thought I have that answered now ahaha.
- empty vs. populated entries: This concerns 'Tags' and 'Comments'
section.
You're put 'Tags' and the
'Welcome' message on the same level because
they
both have 3 rows of content, but this is not the
case when 'Tags' are
used
and populated (you will not have this consistency
any more). When you are
logged-in, the 'Comments' section has another structure and would be
interesting to see how you want to display a comment too. Also you've
removed the 'Activity Stream' which is an important part.
Have a look at
http://incubator.myxwiki.org/xwiki/bin/view/Main/WebHomewhich
shows a wiki instance used: there are lots of spaces, lots of
activity entries, some tags, some comments.
Thank you for this link! I had a copy of XWIKI installed, but there was
nothing in it, so it did not help much. (eg. activity streams and so forth)
There is a Forum view of the mails
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
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
in order to get a better sense of what you can add. Also check out our
Extensions
Furthermore, this skin will really put the content front and center. And
again, this mockup is incomplete, i just wanted to give you a heads up on
this current exploration and was wondering your thoughts.
Again sorry, I'm still trying to get used to everything. Thank you for all
the inputs. I hope to be able to ramp up communication once school is
out--nearing critical point atm so a little bit busy.
Thanks all!,
Jonathan Solichin
[1]
http://mobile-patterns.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs