27 Jun
2012
27 Jun
'12
1:24 p.m.
Hello friends,
The root application >> wikis >> spaces
in a wiki >> Pages in a space.
If you reveal that in the menu users get the intuitive feeling that they
can create a wiki also. And in a wiki they can have spaces and etc...
Well the first time I used XWiki my intuition was to use the drop down at
space to get a list of spaces.I thought the document index would list the
spaces available.
Ah ok, I think I understand what you mean. Clarify if I am wrong: on the
bread crumb, you think that it would be a good idea if it listed the
adjacent areas in the drop down.
eg. if you hover over the pages, it will reveal all the pages in the same
space as the current document.
As a status update. I've done most of the mobile of the skin. Go ahead and
try it in your respective browser: http://jssolichin.com/xwiki. I have
presently tested it on android and Windows Phone along with browser resize
on Chrome. Trying to get my hands on some iphone/blackberry. Let me know
any glaring issues on those browsers in the mean time.
What do you guys think about my implementation/solution to the sidebar? I
handled the swiping a bit differently than the Coffin example. The issue
with coffin is that it seems that it is not cross compatible. The swipe
gesture does not work on WP7 nor on a browser. If you load coffin in a
browser with a small viewport, you lose the ability to scroll completely
and have no way to access the rest of the pages or the menu (unless i'm
doing it wrong).
The way I solved this issue is by making the sidebar in a negative
position. In the mobile browser I tested, it seems to disregard this, so
you can still swipe to see the sidebar. But since you can not do this is a
desktop browser, i implemented the links to access it (sort of reminiscent
of WP's right arrow for apps access). Another benefit is that it allows the
browser to natively direct user to a specific div using #. So if I sent
someone a link to http://jssolichin.com/xwiki#attachments, it should load
the webpage in that area (also why I used scrolling instead of tabs). What
do you guys think?
One thing that I am wondering though is, sometimes a few lines of extra
code is needed to make sure all the feature work properly upon resize.
Should I worry about this? Like if a viewer resizes the browser from a
desktop to a mobile size, should I add extra lines to make sure he can view
it correctly? A lot of this has to do with the resizing capability of the
sidebar (which can't be accomplished with css).
Next step: implement all the drop down and test compatibility on mobile (as
I can get a hold of them) and firefox/safari/ie. Also, begin porting over
to xwiki/simplifying/standardizing.
Thanks friends!
JS
28 Jun
28 Jun
7:01 p.m.
New subject: [xwiki-devs] [GSoC] Responsive Skin
Hi Jonathan,
Some interaction/consistency/usability feedback for
http://jssolichin.com/xwiki/:
- the .nav-icons section could work as a toolbar and every action could
take you to the appropriate anchor (for example: clicking on the
history-clock icon should take you to #history)
- not every entry in the toolbar should have a counter, for example Main,
History, Info is confusing to have counters. The only relevant counters IMO
are the Comments, Annotations, Attachments;
- when you are using the .nav-control, the items in the navigation have
counters near the type, like "Attachments 3". Would be nice to have this
counter too when manually scrolling the navigation, like have the counter
not only on .attachments-link but also on #attachments-wrapper h2
- in recent versions of XWiki (since 4.0) Comments are merged with
Annotations - good to know that :)
- "Main" section content: "Last Modified", "Created",
"Tags" can be put in
the "Information" section although the last editor could be put near the
page title somewhere in order to be able to scan rapidly;
- "Main" naming of the section is kind of confusing since "Main" is
also
the name of a space in XWiki. If you removed the things mentioned above you
can call it "Navigation" or something else, since it will contain table of
content, quicklinks, recent, etc. (mostly panels content)
- you could have a separate "Actions" section that contains page actions:
edit, export, etc.
Just for your information, I don't know if you've read my proposal about
Collaborative Editing
http://incubator.myxwiki.org/xwiki/bin/view/Improvements/CollaborativeEditi…
Although the topic is different from your project, you can see some mockups
of another possible skin for XWiki. Is build with Twitter Bootstrap just
like Jerome's Lyrebird. Could be useful to have as inspiration or at least
to know about it.
Thanks,
Caty
On Wed, Jun 27, 2012 at 2:24 PM, Jonathan Solichin <jssolichin(a)gmail.com>wrote;wrote:
Hello friends,
The root application >> wikis >>
spaces in a wiki >> Pages in a space.
If you reveal that in the menu users get the intuitive feeling that they
can create a wiki also. And in a wiki they can have spaces and etc...
Well the first time I used XWiki my intuition was to use the drop down at
space to get a list of spaces.I thought the document index would list the
spaces available.
Ah ok, I think I understand what you mean. Clarify if I am wrong: on the
bread crumb, you think that it would be a good idea if it listed the
adjacent areas in the drop down.
eg. if you hover over the pages, it will reveal all the pages in the same
space as the current document.
As a status update. I've done most of the mobile of the skin. Go ahead and
try it in your respective browser: http://jssolichin.com/xwiki. I have
presently tested it on android and Windows Phone along with browser resize
on Chrome. Trying to get my hands on some iphone/blackberry. Let me know
any glaring issues on those browsers in the mean time.
What do you guys think about my implementation/solution to the sidebar? I
handled the swiping a bit differently than the Coffin example. The issue
with coffin is that it seems that it is not cross compatible. The swipe
gesture does not work on WP7 nor on a browser. If you load coffin in a
browser with a small viewport, you lose the ability to scroll completely
and have no way to access the rest of the pages or the menu (unless i'm
doing it wrong).
The way I solved this issue is by making the sidebar in a negative
position. In the mobile browser I tested, it seems to disregard this, so
you can still swipe to see the sidebar. But since you can not do this is a
desktop browser, i implemented the links to access it (sort of reminiscent
of WP's right arrow for apps access). Another benefit is that it allows the
browser to natively direct user to a specific div using #. So if I sent
someone a link to http://jssolichin.com/xwiki#attachments, it should load
the webpage in that area (also why I used scrolling instead of tabs). What
do you guys think?
One thing that I am wondering though is, sometimes a few lines of extra
code is needed to make sure all the feature work properly upon resize.
Should I worry about this? Like if a viewer resizes the browser from a
desktop to a mobile size, should I add extra lines to make sure he can view
it correctly? A lot of this has to do with the resizing capability of the
sidebar (which can't be accomplished with css).
Next step: implement all the drop down and test compatibility on mobile (as
I can get a hold of them) and firefox/safari/ie. Also, begin porting over
to xwiki/simplifying/standardizing.
Thanks friends!
JS
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2 Jul
2 Jul
7:22 p.m.
New subject: [xwiki-devs] [GSoC] Responsive Skin
Hi Jonathan,
First, great work overall. I think we are on the right track to make
something great out of this summer of code!
I think the next step is to start integrating with XWiki. We'll probably
hit more real world problems doing this :)
You can create a repo on your github account or we can create one in
xwiki-contrib if you prefer. What you be great would be to have a pom.xml
for it, you can take inspiration from the one I've made for Lyrebird for
example. I can help you with that if you need.
Couple of random remarks :
* I think by default Annotation and Comments UIs should be merged, just
like they are now on a standard XE.
* we need to think how the "search suggest" (search results as you type)
will integrate
* you can also start to think about the "edit" mode (say with the WYSIWYG
editor to begin with).
I'll create new threads to address more specific topics.
Jerome
On Wed, Jun 27, 2012 at 1:24 PM, Jonathan Solichin <jssolichin(a)gmail.com>wrote;wrote:
Hello friends,
--
Jérôme Velociter
Winesquare
http://www.winesquare.net/
The root application >> wikis >>
spaces in a wiki >> Pages in a space.
If you reveal that in the menu users get the intuitive feeling that they
can create a wiki also. And in a wiki they can have spaces and etc...
Well the first time I used XWiki my intuition was to use the drop down at
space to get a list of spaces.I thought the document index would list the
spaces available.
Ah ok, I think I understand what you mean. Clarify if I am wrong: on the
bread crumb, you think that it would be a good idea if it listed the
adjacent areas in the drop down.
eg. if you hover over the pages, it will reveal all the pages in the same
space as the current document.
As a status update. I've done most of the mobile of the skin. Go ahead and
try it in your respective browser: http://jssolichin.com/xwiki. I have
presently tested it on android and Windows Phone along with browser resize
on Chrome. Trying to get my hands on some iphone/blackberry. Let me know
any glaring issues on those browsers in the mean time.
What do you guys think about my implementation/solution to the sidebar? I
handled the swiping a bit differently than the Coffin example. The issue
with coffin is that it seems that it is not cross compatible. The swipe
gesture does not work on WP7 nor on a browser. If you load coffin in a
browser with a small viewport, you lose the ability to scroll completely
and have no way to access the rest of the pages or the menu (unless i'm
doing it wrong).
The way I solved this issue is by making the sidebar in a negative
position. In the mobile browser I tested, it seems to disregard this, so
you can still swipe to see the sidebar. But since you can not do this is a
desktop browser, i implemented the links to access it (sort of reminiscent
of WP's right arrow for apps access). Another benefit is that it allows the
browser to natively direct user to a specific div using #. So if I sent
someone a link to http://jssolichin.com/xwiki#attachments, it should load
the webpage in that area (also why I used scrolling instead of tabs). What
do you guys think?
One thing that I am wondering though is, sometimes a few lines of extra
code is needed to make sure all the feature work properly upon resize.
Should I worry about this? Like if a viewer resizes the browser from a
desktop to a mobile size, should I add extra lines to make sure he can view
it correctly? A lot of this has to do with the resizing capability of the
sidebar (which can't be accomplished with css).
Next step: implement all the drop down and test compatibility on mobile (as
I can get a hold of them) and firefox/safari/ie. Also, begin porting over
to xwiki/simplifying/standardizing.
Thanks friends!
JS
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4512
days inactive
4517
days old
2 comments
3 participants
participants (3)
-
Ecaterina Moraru (Valica) -
Jerome Velociter -
Jonathan Solichin