On Tue, Jul 3, 2012 at 11:51 AM, Jonathan Solichin <[email protected]>wrote:

> Hello friends,
>
>
> > - 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;
>
> oops, copy and paste carelessness. Thanks
>
> - 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)
> > - 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
>
> Good calls, implemented.
>
> - in recent versions of XWiki (since 4.0) Comments are merged with
> > Annotations - good to know that :)
>
>
> * I think by default Annotation and Comments UIs should be merged, just
> > like they are now on a standard XE.
>
> Thank you, for the notice.
>
>
> > - "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;
>
>
>
Hi Jonathan,

Nice to see the improvements you did.


> - you could have a separate "Actions" section that contains page actions:
> > edit, export, etc.
>
> I moved the modified/created/tags into the information-- makes more sense.
> I created two new icons: edit and export to keep "edit" and "export"
> visible and more uniform/extendable (can have more options). What do you
> think of this solution? Or do you think I should consolidate edit and
> export into "actions"? I grouped it in that way originally (or at least in
> the source, and visually), but I thought as a section itself it might have
> been too vague/doesn't really convey what "actions" are, until you click on
> it--so I opted to separate them so it's more apparent what the viewer can
> do. Let me know what your opinion is on this.
>

Regarding this change, my only observation is an usability one. What are
the most common actions a user will want to do on this page? Navigate away
from the page? See comments? See informations?
IMO edit action should not be the last in the menu. Maybe you could move
edit and export to be more visible or closer to the content. A quick
solution would be to put the items in the beginning of the list and not at
the end. This way the user doesn't need to scroll all the way down for them.

Good luck with the implementation part :)
Thanks,
Caty


>
> - "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)
>
> Makes sense. Thanks
>
> 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/CollaborativeEditing
>
> Thank you, seems really interesting. Beautiful graphs/statistics are super
> engaging. The collaborative tool I think is definitely really useful as
> well--I know it is a big sticking point for gdocs.
>
> 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.
>
> yes, it has been very useful to learn more as I integrate.
>
> First, great work overall. I think we are on the right track to make
> > something great out of this summer of code!
>
> Thank you. Definitely great support from you and the community. Learning a
> lot in the process.
>
> I think the next step is to start integrating with XWiki. We'll probably
> > hit more real world problems doing this :)
>
> I agree, I have started doing this, but am already running into a few
> problems. The last couple days I was cleaning up the code/optimizing to
> prepare for this. I now tested the codes in firefox/chrome/opera/safari &
> android/wp/ blackberry(minor issue with it's inability to rotate
> text--thinking of a solution). The code also now implements html5 elements.
>
> 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.
>
> Here is the github for the implementation:
> https://github.com/jssolichin/xo5
>
> I have a question about this. I know pom.xml is used to build for maven,
> but is it necessary for a skin/what other purpose does it serve? At the
> moment I'm just dropping files into: "webapps\xwiki\skins\"--since when I
> build Lyrebird, i get the xar (which i uploaded through the
> admin--something I don't see is needed yet since they are just
> configuration files for the skin right?) and the zip (which i unzip into
> the skins directory). Sorry If I am missing something big.
>
> Also, here is my understanding of xwiki skin, correct me if I'm wrong (
> http://platform.xwiki.org/xwiki/bin/view/DevGuide/Skins seems to mostly be
> overriding than an overall change--is there another guide I am not
> seeing?). XWIKI sees the skin folder and looks for .vm files. If a .vm is
> not found in that skin's folder, it goes to the .vm in the templates
> folder. .vm calls on other .VMs for parts.
>
> My questions are:
> *Is there a way to see which .vm something is coming from? like a developer
> view or sth, that shows  where all the parts are coming from (presently I
> am just ctrl+f the folder for a markup nearby to the things I want to
> change/add--doesn't seem to be very efficient.)
> *Is there a list of default .VMs that xwiki looks for? (this maybe over
> simplifying it, but like in wordpress, a skin has a core of index.php(main
> landing page), single.php(each post), archive.php (search/archive) etc. and
> they call on arbritary .php parts (eg. header.php, footer.php etc.)). Or am
> I thinking about this the wrong way?
> *I know this sounds a little bit vague, but what was your workflow in
> implementing bootstrap? I have to admit, I'm a little bit lost, and I'm
> afraid that I am going about this all the wrong way.
> *A more specific question, which you may not have time to answer, but
> presently I am stuck in coding the global breadcrumb section. So the way I
> am seeing it, it is being pulled from the menuview.vm, which calls upon
> macros.vm. I am changing the macros.vm (say to remove the down triangle  ▼
> ),
> but it seems that it is not changing the skin at all. Am I doing this
> incorrectly?/is there a cache not clearing? (this is in the repo xo5)
>
> On Code Style (http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle):
> *If I click the velocity, it leads me to an editor and not an article?
>
> Couple of random remarks :
>
> > * we need to think how the "search suggest" (search results as you type)
> > will integrate
>
> what if it replaces the main content area (where the article is for that
> page)?
>
>
> > * you can also start to think about the "edit" mode (say with the WYSIWYG
> > editor to begin with).
>
> Ok!
>
> Sorry if this all sounds really basic/there is an article that I am not
> reading (or I am missing/didn't see). If you could point me in the right
> direction, that would be sweet. Thank you again for all the patience and
> support!
>
> Best,
> Jonathan Solichin
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs

Reply via email to