[xwiki-devs] [Proposal] XWiki 2.0 Skin
Hi devs, You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :) Thanks, Caty
On Aug 7, 2009, at 7:13 PM, Ecaterina Valica wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
* General: I like it a lot * What happens when you click "Edit"? Is it possible to go in a given edit mode in one click? Future: * I'd like to see if there's a way to group tags at the top with the rest + potentially move all page information to the top somewhere Thanks -Vincent
err... the bumblebee will not be there right? :) Thanks -Vincent On Aug 7, 2009, at 7:19 PM, Vincent Massol wrote:
On Aug 7, 2009, at 7:13 PM, Ecaterina Valica wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
* General: I like it a lot * What happens when you click "Edit"? Is it possible to go in a given edit mode in one click?
Future: * I'd like to see if there's a way to group tags at the top with the rest + potentially move all page information to the top somewhere
Thanks -Vincent
And just to be sure: the 3 column view is just an example of what it would like and not a default, right? (it would be too large if it were on by default). Thanks -Vincent On Aug 7, 2009, at 7:20 PM, Vincent Massol wrote:
err... the bumblebee will not be there right? :)
Thanks -Vincent
On Aug 7, 2009, at 7:19 PM, Vincent Massol wrote:
On Aug 7, 2009, at 7:13 PM, Ecaterina Valica wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
* General: I like it a lot * What happens when you click "Edit"? Is it possible to go in a given edit mode in one click?
Future: * I'd like to see if there's a way to group tags at the top with the rest + potentially move all page information to the top somewhere
Thanks -Vincent
Hi, On Fri, Aug 7, 2009 at 7:21 PM, Vincent Massol <[email protected]> wrote:
And just to be sure: the 3 column view is just an example of what it would like and not a default, right?
(it would be too large if it were on by default).
It's just an example, you can have the layout you want.
Thanks -Vincent
On Aug 7, 2009, at 7:20 PM, Vincent Massol wrote:
err... the bumblebee will not be there right? :)
Don't worry, the bees are there only here to demonstrate that it will be easy to use a background-image behind the logo if needed ;-) They won't be there in the final skin.
Thanks -Vincent
On Aug 7, 2009, at 7:19 PM, Vincent Massol wrote:
On Aug 7, 2009, at 7:13 PM, Ecaterina Valica wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
* General: I like it a lot * What happens when you click "Edit"? Is it possible to go in a given edit mode in one click?
If you look at the interaction example given, you'll see that you can either click straight on "Edit" which brings you to the default edition mode or hover over Edit and the various edition options will show up. See http://www.sohtanaka.com/web-design/examples/horizontal-subnav/ for the concept.
Future:
* I'd like to see if there's a way to group tags at the top with the rest + potentially move all page information to the top somewhere
Another option I thought about was to put the page information stuff in the Information tab, leave the tabs at the bottom in edit mode, and when in edit mode put the focus on the information tab and make the parent and syntax editable from there. I'm afraid putting too much information at the top would make the document header too heavy.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I like this proposal quite much too :-) Guillaume -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Vincent Massol wrote:
On Aug 7, 2009, at 7:13 PM, Ecaterina Valica wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
Future: * I'd like to see if there's a way to group tags at the top with the rest + potentially move all page information to the top somewhere
You can't have everything at the top. And I wouldn't like it. When I come to a page, I want to see the content. "Content is King". Everybody who ever used the Web knows that comments are at the bottom. Attachments too. In many blog platforms tags are at the bottom as well. People know this. If not, they can learn it. WikiPatterns lists a lot of patterns that can push the wiki forward or backward, but most of them are about people, and not about the placement of things in the UI. People should encourage each other to use tags and comments; the fact that we push them higher on the page doesn't mean that people will start using them more often; it just annoys by standing between the user and the content. And after I read the article and I'm at the bottom, I have to scroll back up to tag or rate it. Or should I tag a document before actually reading it? Anyway, I'd really like to hear more from our users on this topic. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Aug 7, 2009, at 9:29 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
On Aug 7, 2009, at 7:13 PM, Ecaterina Valica wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
Future: * I'd like to see if there's a way to group tags at the top with the rest + potentially move all page information to the top somewhere
You can't have everything at the top. And I wouldn't like it. When I come to a page, I want to see the content. "Content is King". Everybody who ever used the Web knows that comments are at the bottom. Attachments too. In many blog platforms tags are at the bottom as well. People know this. If not, they can learn it.
What I'd like actually is not the actual content on top of course but an easy way to navigate to that content (info, attachments, comments, etc). Right now we kind of have this already with the action toolbar but I have the feeling it can be improved and it doesn't have a link to the page info for example. Here's a example: http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+C... If you're logged in then the Tools menu has more actions. - One think I like is the link to view the latest change directly at the top (in the line that says who was the last modifier). - Another nice thing is the little icon showing the attachment and the number of attachments FOSWiki also does it with icons and I don't feel they're standing in the way of the content: http://foswiki.org/ Last, Lauren't experiment on http://laurent.myxwiki.org/xwiki/bin/view/ModificationVM/ shows everything at the top. I don't know how well or how badly it would work but it doesn't look too bad.
WikiPatterns lists a lot of patterns that can push the wiki forward or backward, but most of them are about people, and not about the placement of things in the UI. People should encourage each other to use tags and comments; the fact that we push them higher on the page doesn't mean that people will start using them more often; it just annoys by standing between the user and the content. And after I read the article and I'm at the bottom, I have to scroll back up to tag or rate it. Or should I tag a document before actually reading it?
I also don't want to clutter things. I hate clutter. I'm not sure about tags at the top. Twiki does it but I don't like the way they've done it. I remember seeing somewhere where it was done in a non obtrusive way. however if we already have one line for the last updated it might be too much to have another one maybe. Lauren't page does it nicely also I think. Thanks -Vincent
Anyway, I'd really like to hear more from our users on this topic.
Vincent Massol wrote: > On Aug 7, 2009, at 9:29 PM, Sergiu Dumitriu wrote: > >> Vincent Massol wrote: >>> On Aug 7, 2009, at 7:13 PM, Ecaterina Valica wrote: >>> >>>> Hi devs, >>>> >>>> You can see the proposal for the new skin at >>>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 >>>> Comments, opinions and implementation help are welcomed :) >>> Future: >>> * I'd like to see if there's a way to group tags at the top with the >>> rest + potentially move all page information to the top somewhere >> You can't have everything at the top. And I wouldn't like it. When I >> come to a page, I want to see the content. "Content is King". >> Everybody >> who ever used the Web knows that comments are at the bottom. >> Attachments >> too. In many blog platforms tags are at the bottom as well. People >> know >> this. If not, they can learn it. > > What I'd like actually is not the actual content on top of course but > an easy way to navigate to that content (info, attachments, comments, > etc). > Right now we kind of have this already with the action toolbar but I > have the feeling it can be improved and it doesn't have a link to the > page info for example. > > Here's a example: > http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+Changes > > If you're logged in then the Tools menu has more actions. > > - One think I like is the link to view the latest change directly at > the top (in the line that says who was the last modifier). > - Another nice thing is the little icon showing the attachment and the > number of attachments > > FOSWiki also does it with icons and I don't feel they're standing in > the way of the content: > http://foswiki.org/ The main difference between Confluence/TWiki and XWiki is that they have only links, while we actually display the information. Indeed, having just the links to view comments/attachments/tags at the bottom would be wrong. But we're actually displaying them, which is completely different from putting a link in a toolbar. Thus, comparing the TWiki UI with ours is like "apples and oranges". > Last, Lauren't experiment on http://laurent.myxwiki.org/xwiki/bin/view/ModificationVM/ > shows everything at the top. I don't know how well or how badly it > would work but it doesn't look too bad. I don't know, I'm not too fond of it. It's invisible information that appears only if you know how to make it visible. I am forced to click to access it. For example the tags are a pretty important piece information (that's why we're considering moving them at the top, to make it more visible), yet I have to click on a label to actually see them. Not to mention that they're unavailable without javascript. Second, when this information appears, it blocks the main content. If we were to put the comments in the same way, as a visitor I wouldn't notice them, and when I open them up, I can't see the content anymore. How can I comment if I can't see what I'm commenting about? >> WikiPatterns lists a lot of patterns that can push the wiki forward or >> backward, but most of them are about people, and not about the >> placement >> of things in the UI. People should encourage each other to use tags >> and >> comments; the fact that we push them higher on the page doesn't mean >> that people will start using them more often; it just annoys by >> standing >> between the user and the content. And after I read the article and I'm >> at the bottom, I have to scroll back up to tag or rate it. Or should I >> tag a document before actually reading it? > > I also don't want to clutter things. I hate clutter. > > I'm not sure about tags at the top. Twiki does it but I don't like the > way they've done it. I remember seeing somewhere where it was done in > a non obtrusive way. however if we already have one line for the last > updated it might be too much to have another one maybe. Lauren't page > does it nicely also I think. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Aug 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote: > Vincent Massol wrote: >> On Aug 7, 2009, at 9:29 PM, Sergiu Dumitriu wrote: >> >>> Vincent Massol wrote: >>>> On Aug 7, 2009, at 7:13 PM, Ecaterina Valica wrote: >>>> >>>>> Hi devs, >>>>> >>>>> You can see the proposal for the new skin at >>>>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 >>>>> Comments, opinions and implementation help are welcomed :) >>>> Future: >>>> * I'd like to see if there's a way to group tags at the top with >>>> the >>>> rest + potentially move all page information to the top somewhere >>> You can't have everything at the top. And I wouldn't like it. When I >>> come to a page, I want to see the content. "Content is King". >>> Everybody >>> who ever used the Web knows that comments are at the bottom. >>> Attachments >>> too. In many blog platforms tags are at the bottom as well. People >>> know >>> this. If not, they can learn it. >> >> What I'd like actually is not the actual content on top of course but >> an easy way to navigate to that content (info, attachments, comments, >> etc). >> Right now we kind of have this already with the action toolbar but I >> have the feeling it can be improved and it doesn't have a link to the >> page info for example. >> >> Here's a example: >> http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+Changes >> >> If you're logged in then the Tools menu has more actions. >> >> - One think I like is the link to view the latest change directly at >> the top (in the line that says who was the last modifier). >> - Another nice thing is the little icon showing the attachment and >> the >> number of attachments >> >> FOSWiki also does it with icons and I don't feel they're standing in >> the way of the content: >> http://foswiki.org/ > > The main difference between Confluence/TWiki and XWiki is that they > have > only links, while we actually display the information. Indeed, having > just the links to view comments/attachments/tags at the bottom would > be > wrong. But we're actually displaying them, which is completely > different > from putting a link in a toolbar. Thus, comparing the TWiki UI with > ours > is like "apples and oranges". > >> Last, Lauren't experiment on http://laurent.myxwiki.org/xwiki/bin/view/ModificationVM/ >> shows everything at the top. I don't know how well or how badly it >> would work but it doesn't look too bad. > > I don't know, I'm not too fond of it. It's invisible information that > appears only if you know how to make it visible. I am forced to > click to > access it. For example the tags are a pretty important piece > information > (that's why we're considering moving them at the top, to make it more > visible), yet I have to click on a label to actually see them. Not to > mention that they're unavailable without javascript. > > Second, when this information appears, it blocks the main content. > If we > were to put the comments in the same way, as a visitor I wouldn't > notice > them, and when I open them up, I can't see the content anymore. How > can > I comment if I can't see what I'm commenting about? I think I'd always keep comments and attachments at the bottom. I don't have a strong opinion on all this, I'd just like that we don't discard this possibility when we make further proposals. In any case we're getting ahead of ourselves since the current proposal is only for XWiki 2.0 and doesn't include all this.... :) The only thing that I currently find a bit strange is the new footer which creates a new zone. So basically we have 3 zones for page info: - top of the doc with breadcrumb - first footer with author + tags - second footer with the tabs. Thanks -Vincent > >>> WikiPatterns lists a lot of patterns that can push the wiki >>> forward or >>> backward, but most of them are about people, and not about the >>> placement >>> of things in the UI. People should encourage each other to use tags >>> and >>> comments; the fact that we push them higher on the page doesn't mean >>> that people will start using them more often; it just annoys by >>> standing >>> between the user and the content. And after I read the article and >>> I'm >>> at the bottom, I have to scroll back up to tag or rate it. Or >>> should I >>> tag a document before actually reading it? >> >> I also don't want to clutter things. I hate clutter. >> >> I'm not sure about tags at the top. Twiki does it but I don't like >> the >> way they've done it. I remember seeing somewhere where it was done in >> a non obtrusive way. however if we already have one line for the last >> updated it might be too much to have another one maybe. Lauren't page >> does it nicely also I think.
Hi, On Fri, Aug 7, 2009 at 10:27 PM, Vincent Massol <[email protected]> wrote: > > On Aug 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote: > > > Vincent Massol wrote: > >> On Aug 7, 2009, at 9:29 PM, Sergiu Dumitriu wrote: > >> > >>> Vincent Massol wrote: > >>>> On Aug 7, 2009, at 7:13 PM, Ecaterina Valica wrote: > >>>> > >>>>> Hi devs, > >>>>> > >>>>> You can see the proposal for the new skin at > >>>>> http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 > >>>>> Comments, opinions and implementation help are welcomed :) > >>>> Future: > >>>> * I'd like to see if there's a way to group tags at the top with > >>>> the > >>>> rest + potentially move all page information to the top somewhere > >>> You can't have everything at the top. And I wouldn't like it. When I > >>> come to a page, I want to see the content. "Content is King". > >>> Everybody > >>> who ever used the Web knows that comments are at the bottom. > >>> Attachments > >>> too. In many blog platforms tags are at the bottom as well. People > >>> know > >>> this. If not, they can learn it. > >> > >> What I'd like actually is not the actual content on top of course but > >> an easy way to navigate to that content (info, attachments, comments, > >> etc). > >> Right now we kind of have this already with the action toolbar but I > >> have the feeling it can be improved and it doesn't have a link to the > >> page info for example. > >> > >> Here's a example: > >> > http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+Changes > >> > >> If you're logged in then the Tools menu has more actions. > >> > >> - One think I like is the link to view the latest change directly at > >> the top (in the line that says who was the last modifier). > >> - Another nice thing is the little icon showing the attachment and > >> the > >> number of attachments > >> > >> FOSWiki also does it with icons and I don't feel they're standing in > >> the way of the content: > >> http://foswiki.org/ > > > > The main difference between Confluence/TWiki and XWiki is that they > > have > > only links, while we actually display the information. Indeed, having > > just the links to view comments/attachments/tags at the bottom would > > be > > wrong. But we're actually displaying them, which is completely > > different > > from putting a link in a toolbar. Thus, comparing the TWiki UI with > > ours > > is like "apples and oranges". > > > >> Last, Lauren't experiment on > http://laurent.myxwiki.org/xwiki/bin/view/ModificationVM/ > >> shows everything at the top. I don't know how well or how badly it > >> would work but it doesn't look too bad. > > > > I don't know, I'm not too fond of it. It's invisible information that > > appears only if you know how to make it visible. I am forced to > > click to > > access it. For example the tags are a pretty important piece > > information > > (that's why we're considering moving them at the top, to make it more > > visible), yet I have to click on a label to actually see them. Not to > > mention that they're unavailable without javascript. > > > > Second, when this information appears, it blocks the main content. > > If we > > were to put the comments in the same way, as a visitor I wouldn't > > notice > > them, and when I open them up, I can't see the content anymore. How > > can > > I comment if I can't see what I'm commenting about? > > I think I'd always keep comments and attachments at the bottom. > > I don't have a strong opinion on all this, I'd just like that we don't > discard this possibility when we make further proposals. In any case > we're getting ahead of ourselves since the current proposal is only > for XWiki 2.0 and doesn't include all this.... :) One way to address this would be to display entries from the "view" menu by default while in view mode (similar to what's done in edit mode) and to put the number of comments and attachments next to menu entries in the action -> they would thus act as quicklinks towards the bottom of the page and provide useful information in an elegant fashion. I'll ask Cati if she can draft something that we could assess. It might make the menu interaction a bit weird though... > The only thing that I currently find a bit strange is the new footer > which creates a new zone. So basically we have 3 zones for page info: > - top of the doc with breadcrumb > - first footer with author + tags > - second footer with the tabs. Well, you end up with a content area with a header + footer that look the same, and an additional area at the bottom with the comments, attachments, history & information -> I personally find it clean / it doesn't shock me. Let's see what others think :-) Guillaume Thanks > -Vincent > > > > >>> WikiPatterns lists a lot of patterns that can push the wiki > >>> forward or > >>> backward, but most of them are about people, and not about the > >>> placement > >>> of things in the UI. People should encourage each other to use tags > >>> and > >>> comments; the fact that we push them higher on the page doesn't mean > >>> that people will start using them more often; it just annoys by > >>> standing > >>> between the user and the content. And after I read the article and > >>> I'm > >>> at the bottom, I have to scroll back up to tag or rate it. Or > >>> should I > >>> tag a document before actually reading it? > >> > >> I also don't want to clutter things. I hate clutter. > >> > >> I'm not sure about tags at the top. Twiki does it but I don't like > >> the > >> way they've done it. I remember seeing somewhere where it was done in > >> a non obtrusive way. however if we already have one line for the last > >> updated it might be too much to have another one maybe. Lauren't page > >> does it nicely also I think. > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Last, Lauren't experiment on http://laurent.myxwiki.org/xwiki/bin/view/ModificationVM/ shows everything at the top. I don't know how well or how badly it would work but it doesn't look too bad.
I don't know, I'm not too fond of it. It's invisible information that appears only if you know how to make it visible. I am forced to click to access it. For example the tags are a pretty important piece information (that's why we're considering moving them at the top, to make it more visible), yet I have to click on a label to actually see them. Not to mention that they're unavailable without javascript.
Second, when this information appears, it blocks the main content. If we were to put the comments in the same way, as a visitor I wouldn't notice them, and when I open them up, I can't see the content anymore. How can I comment if I can't see what I'm commenting about?
I agree with Sergiu. It blocks the information and makes it in small little blocks. I don't like popups. Tags should be at the bottom. My question is: do you think "Created by" should be displayed near the Tags or just put it in the "Information" tab?
On Mon, Aug 10, 2009 at 1:06 PM, Ecaterina Valica<[email protected]> wrote:
Second, when this information appears, it blocks the main content. If we were to put the comments in the same way, as a visitor I wouldn't notice them, and when I open them up, I can't see the content anymore. How can I comment if I can't see what I'm commenting about?
I agree with Sergiu. It blocks the information and makes it in small little blocks. I don't like popups.
Note that those popups were just a test, Laurent wanted to see what it'd look like. The last time we discussed it we agreed that it was better to have anchors, by far. Thanks, JV.
Ecaterina Valica wrote:
Last, Lauren't experiment on http://laurent.myxwiki.org/xwiki/bin/view/ModificationVM/ shows everything at the top. I don't know how well or how badly it would work but it doesn't look too bad. I don't know, I'm not too fond of it. It's invisible information that appears only if you know how to make it visible. I am forced to click to access it. For example the tags are a pretty important piece information (that's why we're considering moving them at the top, to make it more visible), yet I have to click on a label to actually see them. Not to mention that they're unavailable without javascript.
Second, when this information appears, it blocks the main content. If we were to put the comments in the same way, as a visitor I wouldn't notice them, and when I open them up, I can't see the content anymore. How can I comment if I can't see what I'm commenting about?
I agree with Sergiu. It blocks the information and makes it in small little blocks. I don't like popups.
Tags should be at the bottom. My question is: do you think "Created by" should be displayed near the Tags or just put it in the "Information" tab?
IMO, "created by" is a pretty important information, maybe more that "last modified by". The information tab is hidden by default, so I think that it's better to put it near the tags. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi, On Mon, Aug 10, 2009 at 4:19 PM, Sergiu Dumitriu <[email protected]> wrote:
Ecaterina Valica wrote:
Last, Lauren't experiment on http://laurent.myxwiki.org/xwiki/bin/view/ModificationVM/ shows everything at the top. I don't know how well or how badly it would work but it doesn't look too bad. I don't know, I'm not too fond of it. It's invisible information that appears only if you know how to make it visible. I am forced to click to access it. For example the tags are a pretty important piece information (that's why we're considering moving them at the top, to make it more visible), yet I have to click on a label to actually see them. Not to mention that they're unavailable without javascript.
Second, when this information appears, it blocks the main content. If we were to put the comments in the same way, as a visitor I wouldn't notice them, and when I open them up, I can't see the content anymore. How can I comment if I can't see what I'm commenting about?
I agree with Sergiu. It blocks the information and makes it in small little blocks. I don't like popups.
Tags should be at the bottom. My question is: do you think "Created by" should be displayed near the Tags or just put it in the "Information" tab?
IMO, "created by" is a pretty important information, maybe more that "last modified by". The information tab is hidden by default, so I think that it's better to put it near the tags.
I agree with Sergiu, it's better to have the "created by" at the bottom of the content rather than in the Information tab. Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi, I should introduce myself, my name is Thibaut, I'm an experience designer, currently in a training at Dassault Systems. My interests are on service design and 2.0 systems for firms. I'm interested about XWiki because we are willing to use it for the Design Platform project. It is a platform for designers to share stories, knowledge etc... And to make experience design easier to understand for firms and for people. I'm sorry to be late at the skin comments. I had a problem with my mail an was wondering why there were no activity on the mailing list. Lol, I'm a dummy... ^_^ (good introdduction to myself I guess...) I already wrote a message to Evalica, yet I'd better put it here. First of all I love this skin. It is very minimalistic, clear, well cutted and all that makes a skin having a good usability... The only point i would say something is the page tabs. I find it to be globaly good, it is about adapation according to context. Here are some examples of personas feedback to introduce it. These are only example, ot generalization of what would think the whoole class of each persona. Also it is made according to my opinion, it does not replace a real study. *** Mathew... Is not used to web and is scared by it *** Ho my god ! There is too many buttons, is it really usefull ? I really get lost. Well, if I click here... ok! pfff... At middle term I have not maid a real effort so I feel uneasy with it. I dont want to touch the other buttons. At long term, ok, I get how it work. I can find what I need. Evrything is there wich is not bad yet I don't really like it. *** John... Is not used to web but has a good will *** There is a lot of buttons. I feel a little bit lost at first sight. Well, having read the tabs titles I understand it. At middle term, when I use it I get a little bit lost because there is a lot of buttons. But I can deal with it and it makes easy to find advanced functions. At long term I finaly use it well, and since evrything is there I can deal with advanced functions easily. It is cool... *** Esmeralda... Is used to web, a little bit geek, yet she rarely use advanced options *** Hey, so i can find evrything here, cool ! Well, not the most immediate to catch but I feel as it will help me. At middle terme I don't use the other buttons very much. In one hand it is good to have it, in an other hand it would be cleared if it was hidden somewhere. At long terme I don't pay attention to it. *** Johan... Is a little geek too, and make an intensive use of advanced options *** Well, really nice. Evrything is there, it is clear. Super ! At middle term i find it to be really nice ! At long terme also ! *** Irina... Is a big geek, use only some of the advanced options *** Ouch, there is a lot of buttons, did they think to beginners ??? At middle term I get a little worried about beginneers. Web should be simple, it is hurting me. Also I get no use of some of the buttons. I would like to able to delet them so it would clear my view. At long term I send a proposition through the mailing list to simplfy it. (Irina never had any real problem with it of course.) Now see the case of the Design Platform. This is a web based open platform for non web specialists. I guess we will have a lot of Mathew, John and Esmeralda. Also we would have a lot of short term reactions since there would be a big part of casual users. Then we will have to adapt our design. We would display only the buttons that are the most immediatly used. Other buttons can be stored in an advanced menu or suppressed for non-admin people. A good thing would be that the developers make it the most easy as possible to personalize. Preferably not having to modify the .vm. So it could be adapted easily to evry special case in order to make an adapted design. Also, if the developpers were really kind they would add an optional horizontal main-menu bar for sites wich need it. Lol, I'm day-dreaming (We will modify the .vm in all cases... ^_^ ). That's all. Ho yes I forgot, I really love the bees... ;-) Have a nice day ! Thibaut -- View this message in context: http://n2.nabble.com/-Proposal--XWiki-2.0-Skin-tp3405623p3453051.html Sent from the XWiki- Dev mailing list archive at Nabble.com.
Precision : The design plaform project is _not_ a Dassault Systems project. ( Even if Dassault Design Studio like it a lot of course ^_^ ) It is an open design project by a team of young designers, researchers and design organisms. -- View this message in context: http://n2.nabble.com/-Proposal--XWiki-2.0-Skin-tp3405623p3453066.html Sent from the XWiki- Dev mailing list archive at Nabble.com.
Sorry 3 mail... I missed the last post. about this skin : http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposal... Well, it is obviously the same architecture as currently. I understand that there is not much time. I hope it is not definitve. I'd really prefer a skin with page related actions located near page. Also I'd love to make propositions of architecture modifications to visauy show my means. Yet I have not many time. Is there a place where source files can be downloaded to speed the process ? Have a nice day Thibaut -- View this message in context: http://n2.nabble.com/-Proposal--XWiki-2.0-Skin-tp3405623p3453159.html Sent from the XWiki- Dev mailing list archive at Nabble.com.
Also I'd love to make propositions of architecture modifications to visauy show my means. Yet I have not many time. Is there a place where source files can be downloaded to speed the process ?
The new skin will be available in it's first version with the RC1 on 24 august.
Nice ! I can't wait to see it. ;-)
Also I'd love to make propositions of architecture modifications to visauy show my means. Yet I have not many time. Is there a place where source files can be downloaded to speed the process ?
The new skin will be available in it's first version with the RC1 on 24 august.
I was speaking of the design source files, not code. :-) Photoshop, Gimp, Illustrator, Inkscape or whatever you use. -- Yet I will wait to see your skin and think I will not make mockup then. Yet in general cases we found having design files open source too can help as we experienced in the design platform project.
Usually I use Inkscape, but for the skin mockups it's not a mockup, but the actually site modified with CSS. I worked on a local XE instance on my computer. On Wed, Aug 19, 2009 at 14:04, Thibaut DEVERAUX <[email protected]>wrote:
Nice ! I can't wait to see it. ;-)
Also I'd love to make propositions of architecture modifications to visauy show my means. Yet I have not many time. Is there a place where source files can be downloaded to speed the process ?
The new skin will be available in it's first version with the RC1 on 24 august.
I was speaking of the design source files, not code. :-)
Photoshop, Gimp, Illustrator, Inkscape or whatever you use.
-- Yet I will wait to see your skin and think I will not make mockup then. Yet in general cases we found having design files open source too can help as we experienced in the design platform project. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Thanks. Where can I find the svg files in the futur ? 2009/8/19 Ecaterina Valica <[email protected]>:
Usually I use Inkscape, but for the skin mockups it's not a mockup, but the actually site modified with CSS. I worked on a local XE instance on my computer.
On Wed, Aug 19, 2009 at 14:04, Thibaut DEVERAUX <[email protected]>wrote:
Nice ! I can't wait to see it. ;-)
Also I'd love to make propositions of architecture modifications to visauy show my means. Yet I have not many time. Is there a place where source files can be downloaded to speed the process ?
The new skin will be available in it's first version with the RC1 on 24 august.
I was speaking of the design source files, not code. :-)
Photoshop, Gimp, Illustrator, Inkscape or whatever you use.
-- Yet I will wait to see your skin and think I will not make mockup then. Yet in general cases we found having design files open source too can help as we experienced in the design platform project. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Sorry, we currently don't have a especially place for SVG files. :) On Wed, Aug 19, 2009 at 18:37, Thibaut DEVERAUX <[email protected]>wrote:
Thanks.
Where can I find the svg files in the futur ?
2009/8/19 Ecaterina Valica <[email protected]>:
Usually I use Inkscape, but for the skin mockups it's not a mockup, but the actually site modified with CSS. I worked on a local XE instance on my computer.
On Wed, Aug 19, 2009 at 14:04, Thibaut DEVERAUX <[email protected]>wrote:
Nice ! I can't wait to see it. ;-)
Also I'd love to make propositions of architecture modifications to visauy show my means. Yet I have not many time. Is there a place where source files can be downloaded to speed the process ?
The new skin will be available in it's first version with the RC1 on 24 august.
I was speaking of the design source files, not code. :-)
Photoshop, Gimp, Illustrator, Inkscape or whatever you use.
-- Yet I will wait to see your skin and think I will not make mockup then. Yet in general cases we found having design files open source too can help as we experienced in the design platform project. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Thibaut, You're right that having all the buttons in one place can be confusing and scary for beginners. Me, G and JV also did some sketches of the menu, where all the complicated (non vital) functions would be placed in "More actions". The menu is still open for discussion and sadly it won't make it in the 2.0 version. Also, about the advanced users we have advanced / simple menu display, which is not perfect at all but this could also solve the problem of advanced / beginners in term of usability. Thanks Thibaut for your use cases :) they were lot of fun :p
What I'd like actually is not the actual content on top of course but an easy way to navigate to that content (info, attachments, comments, etc).
Right now you have an easy way to navigate to that content by using "Show" in the action menu (links to Comments, Attachments, History, Information). The problem with this submenu is that it's not intuitive and not well placed. We have many actions in it and we don't know what are important and what are helpfull. And here comes the discussions about redesigning the information architecture in the menu.
Right now we kind of have this already with the action toolbar but I have the feeling it can be improved and it doesn't have a link to the page info for example.
Here's a example:
http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+C...
If you're logged in then the Tools menu has more actions.
- One think I like is the link to view the latest change directly at the top (in the line that says who was the last modifier). - Another nice thing is the little icon showing the attachment and the number of attachments
FOSWiki also does it with icons and I don't feel they're standing in the way of the content: http://foswiki.org/
The bad things about the examples is that they take you to other page to show you that information and I don't like that. They take away the context.
On Aug 10, 2009, at 1:00 PM, Ecaterina Valica wrote:
What I'd like actually is not the actual content on top of course but an easy way to navigate to that content (info, attachments, comments, etc).
Right now you have an easy way to navigate to that content by using "Show" in the action menu (links to Comments, Attachments, History, Information). The problem with this submenu is that it's not intuitive and not well placed. We have many actions in it and we don't know what are important and what are helpfull. And here comes the discussions about redesigning the information architecture in the menu.
I agree.
Right now we kind of have this already with the action toolbar but I have the feeling it can be improved and it doesn't have a link to the page info for example.
Here's a example:
http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+C...
If you're logged in then the Tools menu has more actions.
- One think I like is the link to view the latest change directly at the top (in the line that says who was the last modifier). - Another nice thing is the little icon showing the attachment and the number of attachments
FOSWiki also does it with icons and I don't feel they're standing in the way of the content: http://foswiki.org/
The bad things about the examples is that they take you to other page to show you that information and I don't like that. They take away the context.
I agree but then it's also a question of how much you have to display. If you look at the info page for confluence you'll see it has a lot of information in it. -Vincent
Vincent Massol wrote:
On Aug 10, 2009, at 1:00 PM, Ecaterina Valica wrote:
What I'd like actually is not the actual content on top of course but an easy way to navigate to that content (info, attachments, comments, etc).
Right now you have an easy way to navigate to that content by using "Show" in the action menu (links to Comments, Attachments, History, Information). The problem with this submenu is that it's not intuitive and not well placed. We have many actions in it and we don't know what are important and what are helpfull. And here comes the discussions about redesigning the information architecture in the menu.
I agree.
Right now we kind of have this already with the action toolbar but I have the feeling it can be improved and it doesn't have a link to the page info for example.
Here's a example:
http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+C...
If you're logged in then the Tools menu has more actions.
- One think I like is the link to view the latest change directly at the top (in the line that says who was the last modifier). - Another nice thing is the little icon showing the attachment and the number of attachments
FOSWiki also does it with icons and I don't feel they're standing in the way of the content: http://foswiki.org/
The bad things about the examples is that they take you to other page to show you that information and I don't like that. They take away the context.
I agree but then it's also a question of how much you have to display. If you look at the info page for confluence you'll see it has a lot of information in it.
And that is bad in two ways. - I think that we display more information than they do, so they're not better than us - Personally, I think that their interface sucks big time. There is no clear separation of the content. Everything is a big heap of text, all looking the same, so it's hard to spot something in there. This shows the true value of using margins and paddings correctly. So they are much worse than us. -- Sergiu Dumitriu http://purl.org/net/sergiu/
About content links: What I'd like actually is not the actual content on top of course but
an easy way to navigate to that content (info, attachments, comments, etc).
Here's a example:
http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+C...
- One think I like is the link to view the latest change directly at the top (in the line that says who was the last modifier). - Another nice thing is the little icon showing the attachment and the number of attachments
FOSWiki also does it with icons and I don't feel they're standing in the way of the content: http://foswiki.org/
Proposal 1: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten... Proposal 2: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten...
On Aug 10, 2009, at 6:29 PM, Ecaterina Valica wrote:
About content links:
What I'd like actually is not the actual content on top of course but
an easy way to navigate to that content (info, attachments, comments, etc).
Here's a example:
http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+C...
- One think I like is the link to view the latest change directly at the top (in the line that says who was the last modifier). - Another nice thing is the little icon showing the attachment and the number of attachments
FOSWiki also does it with icons and I don't feel they're standing in the way of the content: http://foswiki.org/
Proposal 1: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten... Proposal 2: http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten...
I like it. What is under the Show menu now? Thanks -Vincent
It's gonna go the Show submenu - but I didn't touch the menu for now. We need to discuss it. I'm glad you like it, but which versions? contentLinks 1 or 2? :) On Mon, Aug 10, 2009 at 18:35, Vincent Massol <[email protected]> wrote:
On Aug 10, 2009, at 6:29 PM, Ecaterina Valica wrote:
About content links:
What I'd like actually is not the actual content on top of course but
an easy way to navigate to that content (info, attachments, comments, etc).
Here's a example:
http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+C...
- One think I like is the link to view the latest change directly at the top (in the line that says who was the last modifier). - Another nice thing is the little icon showing the attachment and the number of attachments
FOSWiki also does it with icons and I don't feel they're standing in the way of the content: http://foswiki.org/
Proposal 1:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten...
Proposal 2:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten...
I like it. What is under the Show menu now?
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Aug 10, 2009, at 6:43 PM, Ecaterina Valica wrote:
It's gonna go the Show submenu - but I didn't touch the menu for now. We need to discuss it.
I'm glad you like it, but which versions? contentLinks 1 or 2? :)
I thought they were the same. One view showing without numbers and one with numbers. I like that it shows the number of comments/attachments. Re the color I don't mind that much. Thanks -Vincent
On Mon, Aug 10, 2009 at 18:35, Vincent Massol <[email protected]> wrote:
On Aug 10, 2009, at 6:29 PM, Ecaterina Valica wrote:
About content links:
What I'd like actually is not the actual content on top of course but
an easy way to navigate to that content (info, attachments, comments, etc).
Here's a example:
http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+C...
- One think I like is the link to view the latest change directly at the top (in the line that says who was the last modifier). - Another nice thing is the little icon showing the attachment and the number of attachments
FOSWiki also does it with icons and I don't feel they're standing in the way of the content: http://foswiki.org/
Proposal 1:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten...
Proposal 2:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten...
I like it. What is under the Show menu now?
Thanks -Vincent
Meaning for links color: Proposal 1. having separate links color: - dark grey for internal links + JS - blue for external links Proposal 2. having blue for every thing that you can interact with. On Mon, Aug 10, 2009 at 18:56, Vincent Massol <[email protected]> wrote:
On Aug 10, 2009, at 6:43 PM, Ecaterina Valica wrote:
It's gonna go the Show submenu - but I didn't touch the menu for now. We need to discuss it.
I'm glad you like it, but which versions? contentLinks 1 or 2? :)
I thought they were the same. One view showing without numbers and one with numbers. I like that it shows the number of comments/attachments.
Re the color I don't mind that much.
Thanks -Vincent
On Mon, Aug 10, 2009 at 18:35, Vincent Massol <[email protected]> wrote:
On Aug 10, 2009, at 6:29 PM, Ecaterina Valica wrote:
About content links:
What I'd like actually is not the actual content on top of course but
an easy way to navigate to that content (info, attachments, comments, etc).
Here's a example:
http://confluence.atlassian.com/display/DOC/Confluence+2.8+Screen+and+Menu+C...
- One think I like is the link to view the latest change directly at the top (in the line that says who was the last modifier). - Another nice thing is the little icon showing the attachment and the number of attachments
FOSWiki also does it with icons and I don't feel they're standing in the way of the content: http://foswiki.org/
Proposal 1:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten...
Proposal 2:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten...
I like it. What is under the Show menu now?
Thanks -Vincent
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Ecaterina Valica wrote:
Meaning for links color:
Proposal 1. having separate links color:
- dark grey for internal links + JS - blue for external links
Proposal 2. having blue for every thing that you can interact with.
Just in case the opinion of a simple user could be taken into account: option 2 is OK for me. For a regular user is enough to be aware of what elements of a page she/he could interact with without receiving extra information about the details of such an interaction. Thanks for your work, Ricardo -- Ricardo Rodríguez Your EPEC Network ICT Team
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Hi,
Ecaterina Valica wrote:
Meaning for links color:
Proposal 1. having separate links color:
- dark grey for internal links + JS
What do you mean by "+ JS"?
- blue for external links
Proposal 2. having blue for every thing that you can interact with.
Just in case the opinion of a simple user could be taken into account: option 2 is OK for me. For a regular user is enough to be aware of what elements of a page she/he could interact with without receiving extra information about the details of such an interaction.
Normally external links are identified by an icon, not by color. Having links using almost the same color as the text is not a good idea, and having links with two different colors in the same context is confusing. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi, On Tue, Aug 11, 2009 at 12:43 AM, Sergiu Dumitriu <[email protected]> wrote:
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Hi,
Ecaterina Valica wrote:
Meaning for links color:
Proposal 1. having separate links color:
- dark grey for internal links + JS
What do you mean by "+ JS"?
- blue for external links
Proposal 2. having blue for every thing that you can interact with.
Just in case the opinion of a simple user could be taken into account: option 2 is OK for me. For a regular user is enough to be aware of what elements of a page she/he could interact with without receiving extra information about the details of such an interaction.
Normally external links are identified by an icon, not by color. Having links using almost the same color as the text is not a good idea, and having links with two different colors in the same context is confusing.
I like contentLinks2.png best too. I agree with Sergiu on keeping the same color for all links + having the number of comments / attachments is nice too. Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
The main problem with contentLinks2.png and contentLinks1.png is when we are on 1024 monitors and we gonna have problems with the breadcrumbs overlapping the contentLinks. Please take a look at http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/contentLinks3.png(it's a Marta & me effort ): - "Watch Page" is integrated and removed from the actionMenu since it's a toggle action and this way you can visualize if the page is watched without going through the menu; (in the mockups the page is watched) - links to the History and Information are removed, Comments and Attachments being more important to have an easy access. - ratings (when they will be default added) the can be appended after the Comments | Attachments; On Tue, Aug 11, 2009 at 10:44, Guillaume Lerouge <[email protected]>wrote:
Hi,
On Tue, Aug 11, 2009 at 12:43 AM, Sergiu Dumitriu <[email protected]> wrote:
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Hi,
Ecaterina Valica wrote:
Meaning for links color:
Proposal 1. having separate links color:
- dark grey for internal links + JS
What do you mean by "+ JS"?
- blue for external links
Proposal 2. having blue for every thing that you can interact with.
Just in case the opinion of a simple user could be taken into account: option 2 is OK for me. For a regular user is enough to be aware of what elements of a page she/he could interact with without receiving extra information about the details of such an interaction.
Normally external links are identified by an icon, not by color. Having links using almost the same color as the text is not a good idea, and having links with two different colors in the same context is confusing.
I like contentLinks2.png best too. I agree with Sergiu on keeping the same color for all links + having the number of comments / attachments is nice too.
Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Tue, Aug 11, 2009 at 6:02 PM, Ecaterina Valica <[email protected]> wrote:
The main problem with contentLinks2.png and contentLinks1.png is when we are on 1024 monitors and we gonna have problems with the breadcrumbs overlapping the contentLinks.
Please take a look at
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/contentLinks3.png(it's a Marta & me effort ):
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conten... will work better ;-) I like it! Guillaume
- "Watch Page" is integrated and removed from the actionMenu since it's a toggle action and this way you can visualize if the page is watched without going through the menu; (in the mockups the page is watched) - links to the History and Information are removed, Comments and Attachments being more important to have an easy access. - ratings (when they will be default added) the can be appended after the Comments | Attachments;
On Tue, Aug 11, 2009 at 10:44, Guillaume Lerouge <[email protected]
wrote:
Hi,
On Tue, Aug 11, 2009 at 12:43 AM, Sergiu Dumitriu <[email protected]> wrote:
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
Hi,
Ecaterina Valica wrote:
Meaning for links color:
Proposal 1. having separate links color:
- dark grey for internal links + JS
What do you mean by "+ JS"?
- blue for external links
Proposal 2. having blue for every thing that you can interact with.
Just in case the opinion of a simple user could be taken into account: option 2 is OK for me. For a regular user is enough to be aware of what elements of a page she/he could interact with without receiving extra information about the details of such an interaction.
Normally external links are identified by an icon, not by color. Having links using almost the same color as the text is not a good idea, and having links with two different colors in the same context is confusing.
I like contentLinks2.png best too. I agree with Sergiu on keeping the same color for all links + having the number of comments / attachments is nice too.
Guillaume
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
View History Mockup http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageVi...
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
View History Mockup http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageVi...
Sounds good even though I liked the fact that click on the history tab was not reloading a new page (it was fast as a consequence). I'm not sure about hiding minor edits by default. At least if it were hidden by default I'd like that clicking on show would not reload the full page so that it's fast. Thanks -Vincent
Related Pages Mockup http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageVi... We should display the footer with the Tags and Creator also on History and Related Pages?
Hi, On Wed, Aug 12, 2009 at 7:04 PM, Vincent Massol <[email protected]> wrote:
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
View History Mockup
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageVi...
Sounds good even though I liked the fact that click on the history tab was not reloading a new page (it was fast as a consequence).
There's no technical reason why we couldn't use an AJAX call here too and avoid reloading the whole page, is there?
I'm not sure about hiding minor edits by default. At least if it were hidden by default I'd like that clicking on show would not reload the full page so that it's fast.
I'm fine with hiding minor edits because they often contain a lot of clutter. However it would definitely be better if they could be displayed without reloading the whole page. Worst case scenario is that in version 1 of the new skin we have page reload and in the next version we replace them with AJAX calls... We'll need the ability to reload the full page for non-JS enabled browsers anyway. Guillaume Thanks
-Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi, Because of the time constrain the skin might end up looking like this http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposal... Thanks, Caty On Wed, Aug 12, 2009 at 20:06, Guillaume Lerouge <[email protected]>wrote:
Hi,
On Wed, Aug 12, 2009 at 7:04 PM, Vincent Massol <[email protected]> wrote:
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
View History Mockup
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageVi...
Sounds good even though I liked the fact that click on the history tab was not reloading a new page (it was fast as a consequence).
There's no technical reason why we couldn't use an AJAX call here too and avoid reloading the whole page, is there?
I'm not sure about hiding minor edits by default. At least if it were hidden by default I'd like that clicking on show would not reload the full page so that it's fast.
I'm fine with hiding minor edits because they often contain a lot of clutter. However it would definitely be better if they could be displayed without reloading the whole page.
Worst case scenario is that in version 1 of the new skin we have page reload and in the next version we replace them with AJAX calls... We'll need the ability to reload the full page for non-JS enabled browsers anyway.
Guillaume
Thanks
-Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi,
Because of the time constrain the skin might end up looking like this http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposal...
I would suggest, as a simple modification, to change the color of the active tab name. The problem is that it has the same color with its subelements, and the visual effect is that the subelements are mixed with the tab name. The color that I would choose would be a lighter grey, to specify in this way that the tab is active and static (= its subelements are now the primary actions, and if you click it again, the tabs layout will not change). Raluca.
Thanks, Caty
On Wed, Aug 12, 2009 at 20:06, Guillaume Lerouge <[email protected]>wrote:
Hi,
On Wed, Aug 12, 2009 at 7:04 PM, Vincent Massol <[email protected]> wrote:
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
View History Mockup
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageVi...
Sounds good even though I liked the fact that click on the history tab was not reloading a new page (it was fast as a consequence).
There's no technical reason why we couldn't use an AJAX call here too and avoid reloading the whole page, is there?
I'm not sure about hiding minor edits by default. At least if it were hidden by default I'd like that clicking on show would not reload the full page so that it's fast.
I'm fine with hiding minor edits because they often contain a lot of clutter. However it would definitely be better if they could be displayed without reloading the whole page.
Worst case scenario is that in version 1 of the new skin we have page reload and in the next version we replace them with AJAX calls... We'll need the ability to reload the full page for non-JS enabled browsers anyway.
Guillaume
Thanks
-Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi,
Because of the time constrain the skin might end up looking like this http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposal...
I would suggest, as a simple modification, to change the color of the active tab name. The problem is that it has the same color with its subelements, and the visual effect is that the subelements are mixed with the tab name. The color that I would choose would be a lighter grey, to specify in this way that the tab is active and static (= its subelements are now the primary actions, and if you click it again, the tabs layout will not change).
I was referring to the page menu proposal http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1#HPageMenu. Raluca.
Thanks, Caty
On Wed, Aug 12, 2009 at 20:06, Guillaume Lerouge <[email protected]>wrote:
Hi,
On Wed, Aug 12, 2009 at 7:04 PM, Vincent Massol <[email protected]> wrote:
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
View History Mockup
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageVi...
Sounds good even though I liked the fact that click on the history
tab
was not reloading a new page (it was fast as a consequence).
There's no technical reason why we couldn't use an AJAX call here too and avoid reloading the whole page, is there?
I'm not sure about hiding minor edits by default. At least if it were hidden by default I'd like that clicking on show would not reload the full page so that it's fast.
I'm fine with hiding minor edits because they often contain a lot of clutter. However it would definitely be better if they could be displayed without reloading the whole page.
Worst case scenario is that in version 1 of the new skin we have page reload and in the next version we replace them with AJAX calls... We'll need the ability to reload the full page for non-JS enabled browsers anyway.
Guillaume
Thanks
-Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Raluca, Thanks for the comment. Anyway that menu won't make it to XWiki 2.0. Caty On Tue, Aug 18, 2009 at 12:55, Raluca Stavro <[email protected]>wrote:
Hi,
Because of the time constrain the skin might end up looking like this
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposal...
I would suggest, as a simple modification, to change the color of the active tab name. The problem is that it has the same color with its subelements, and the visual effect is that the subelements are mixed with the tab name. The color that I would choose would be a lighter grey, to specify in this way that the tab is active and static (= its subelements are now the primary actions, and if you click it again, the tabs layout will not change).
I was referring to the page menu proposal http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1#HPageMenu .
Raluca.
Thanks, Caty
On Wed, Aug 12, 2009 at 20:06, Guillaume Lerouge <[email protected]>wrote:
Hi,
On Wed, Aug 12, 2009 at 7:04 PM, Vincent Massol <[email protected]> wrote:
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
View History Mockup
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageVi...
Sounds good even though I liked the fact that click on the history
tab
was not reloading a new page (it was fast as a consequence).
There's no technical reason why we couldn't use an AJAX call here too and avoid reloading the whole page, is there?
I'm not sure about hiding minor edits by default. At least if it were hidden by default I'd like that clicking on show would not reload the full page so that it's fast.
I'm fine with hiding minor edits because they often contain a lot of clutter. However it would definitely be better if they could be displayed without reloading the whole page.
Worst case scenario is that in version 1 of the new skin we have page reload and in the next version we replace them with AJAX calls... We'll need the ability to reload the full page for non-JS enabled browsers anyway.
Guillaume
Thanks
-Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Tue, Aug 18, 2009 at 3:44 AM, Raluca Stavro <[email protected]>wrote:
Because of the time constrain the skin might end up looking like this
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposal...
I would suggest, as a simple modification, to change the color of the active tab name. The problem is that it has the same color with its subelements, and the visual effect is that the subelements are mixed with the tab name. The color that I would choose would be a lighter grey, to specify in this way that the tab is active and static (= its subelements are now the primary actions, and if you click it again, the tabs layout will not change).
First, I too like the simplicity/functionality and potential performance-improvements that the new style will give to the XWiki project. However,I am in agreement w/ Raluca Stavro regarding the lack of contrast. I am also disappointed to see the menus being left where they can be "mis-clicked" due to their prior proximity to browser tabs & bookmarks. I liked this better because it has better contrast and less chance of mis clicking: http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1#HPageinVie... In http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposal..., the use of fg=white bg=grey for text makes it hard to read. Since the folder tabs are basically "text icons" they should be instantly recognizable without having to do much "visual work" (as in focusing and reading the text as opposed to taking it all in in a single gestalt/augenblick/coup d'oeil). Can the selected tab be represented instead by having a background change to make the tab look "at the front/selected" while having the foreground change to an eye-catching color (not grey or white) to indicate selection of the "text icon" associated with the tab? Finally, as a future option, it would be nice to have a simple way to "parametrize" the colors across the skin such that Xwiki administration panels would allow for the choice of a few "canned" color-schemes that work well. One is the "corporate/grey" look, usable in the widest range of applications. Another would be "high contrast" which might replace grey/white/grey-shades with color combinations that look good together and have contrast; one could be "tektonic" or some other outrageous youthful avant-garde styling. :-) Thanks for improving the look of Xwiki! -- Niels http://nielsmayer.com
Ecaterina Valica wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
That looks light and clean, it's good to see a nice, simple look without many decorations. Some things are missing, though: * there's no link to Administration; * I see no way to switch to another language. Also, some more improvements need to be included in this new skin, other than just a lighter appearance. For instance, the menu needs to be reorganized: * PRINT has been a wrong term for a very long time, and needs to be changed to EXPORT * I'm not sure we need both VIEW and SHOW; maybe they could be combined? VIEW: Document | Wiki code | ... * WATCH is an entry for which the actual usage is ambiguous (at least in my opinion). To make it more clear, I'd propose: ** to break the entries from the WATCH menu in 2: the one related to the page stays in the page menu, while the "Watch list management" will appear next to "Administration" (probably someplace at the top) ** to make it more clear whether the current document is being watched or not, an empty or full star icon (symbol often used for "favorites") can be placed next to the text. -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Aug 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote:
Ecaterina Valica wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
That looks light and clean, it's good to see a nice, simple look without many decorations.
Some things are missing, though: * there's no link to Administration; * I see no way to switch to another language.
Also, some more improvements need to be included in this new skin, other than just a lighter appearance. For instance, the menu needs to be reorganized: * PRINT has been a wrong term for a very long time, and needs to be changed to EXPORT * I'm not sure we need both VIEW and SHOW; maybe they could be combined? VIEW: Document | Wiki code | ... * WATCH is an entry for which the actual usage is ambiguous (at least in my opinion). To make it more clear, I'd propose: ** to break the entries from the WATCH menu in 2: the one related to the page stays in the page menu, while the "Watch list management" will appear next to "Administration" (probably someplace at the top) ** to make it more clear whether the current document is being watched or not, an empty or full star icon (symbol often used for "favorites") can be placed next to the text.
The office import entry is also strange in its current location. I think JV had done some proposals on the toolbar entries at one point. JV? Note that Cati's proposal was done not to change too many things from the current skin since it needs to be agreed and finalized in the 2.0 time frame. Thanks -Vincent
Hi, On Fri, Aug 7, 2009 at 10:32 PM, Vincent Massol <[email protected]> wrote:
On Aug 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote:
Ecaterina Valica wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
That looks light and clean, it's good to see a nice, simple look without many decorations.
Some things are missing, though: * there's no link to Administration; * I see no way to switch to another language.
I think Cati is aware of this. Both links would find a position somewhere at the top right of the skin IIRC.
Also, some more improvements need to be included in this new skin,
other than just a lighter appearance. For instance, the menu needs to be reorganized: * PRINT has been a wrong term for a very long time, and needs to be changed to EXPORT * I'm not sure we need both VIEW and SHOW; maybe they could be combined? VIEW: Document | Wiki code | ... * WATCH is an entry for which the actual usage is ambiguous (at least in my opinion). To make it more clear, I'd propose: ** to break the entries from the WATCH menu in 2: the one related to the page stays in the page menu, while the "Watch list management" will appear next to "Administration" (probably someplace at the top) ** to make it more clear whether the current document is being watched or not, an empty or full star icon (symbol often used for "favorites") can be placed next to the text.
The office import entry is also strange in its current location.
I think JV had done some proposals on the toolbar entries at one point. JV?
Note that Cati's proposal was done not to change too many things from the current skin since it needs to be agreed and finalized in the 2.0 time frame.
We (Cati +JV + me) will write and send a couple proposals for a reworked action bar to be included in the new skin ASAP. Guillaume
Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Ecaterina Valica-2 wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Since part of my new job is to provide suggestions regarding usability matters I thought as a start I might provide some observations on the new skin :-) First of all I like the new skin a lot. It's minimalistic and the content is organized so the users can make the most of it. The following is a list of suggestions that I think would make the user experience even better. The user I am referring to is not the web-savvy kind, but a user with a minimal browsing experience. Skin: View->Content - It would be great if there was a link where people who had trouble with the wiki could go for help. This could be a link to all documentation, the user guide, etc. - "Query" is a term users that are not internet-savvy may not understand. I suggest writing "Search" in the search box. This would make "Search my wiki" redundant, so I suggest removing the text above the search box altogether. - Users may not be familiar with some of the languages the wiki is available in. As a result they may fail to identify the current language if it is not marked distinctively (e.g. Current language could be a blue button). - The terms "Administration Administrator" at the top of the page are redundant and may cause confusion. Users may not understand why the word is repeated. I suggest replacing "Administration" with "Loged-in as". - While the first 3 actions in the “View” menu (Content, Source, History) are connected, I think "Related Pages" would make more sense in "Quick Links". This would also make it easier for the user to consult other similar pages and overall increase his use of the wiki. - I suggest adding a "view change" link next to the last modification date. This will provide non-experienced users with quick access to modifications in case they don't know what the "History" tab does. - I think it would be better if we had tags under the title. I agree people will most likely add tags after they have read the content. However tags may also be used to find similar information that users can skim through while reading the current article. (e.g.: I am reading an article about a Beatles album on a wiki. As soon as I open the page I will click on “The Beatles” tag under the title and open it in a new tab in order to find out more about their other albums. I will be reading these pages in parallel and making comparisons). As an alternative we could have a tag list/cloud in the right panel. Skin: WYSIWYG The preview button at the bottom of the page should be the first button, as the user is likely to click on it a few times before he saves and publishes the content. Skin: View->History I think the "previous page" button should be in front of the first page, while the "next page" button should stay after the 9th page. This is a system users are already familiar with. Hope this is useful ;-) -- View this message in context: http://n2.nabble.com/Proposal-XWiki-2-0-Skin-tp3405623p3486071.html Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi Silvia, Silvia Rusu wrote:
Ecaterina Valica-2 wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi,
Since part of my new job is to provide suggestions regarding usability matters I thought as a start I might provide some observations on the new skin :-)
First of all I like the new skin a lot. It's minimalistic and the content is organized so the users can make the most of it. The following is a list of suggestions that I think would make the user experience even better. The user I am referring to is not the web-savvy kind, but a user with a minimal browsing experience.
Skin: View->Content
- It would be great if there was a link where people who had trouble with the wiki could go for help. This could be a link to all documentation, the user guide, etc.
- "Query" is a term users that are not internet-savvy may not understand. I suggest writing "Search" in the search box. This would make "Search my wiki" redundant, so I suggest removing the text above the search box altogether.
- Users may not be familiar with some of the languages the wiki is available in. As a result they may fail to identify the current language if it is not marked distinctively (e.g. Current language could be a blue button).
- The terms "Administration Administrator" at the top of the page are redundant and may cause confusion. Users may not understand why the word is repeated. I suggest replacing "Administration" with "Loged-in as".
The two words are in fact links to two different things: * Administration: link to the wiki administration page * Administrator: link to the profile of the currently logged in user Your comment proves that: * it's not clear that they are links * it's not clear that they are separated We should definitely improve this. Marius
- While the first 3 actions in the “View” menu (Content, Source, History) are connected, I think "Related Pages" would make more sense in "Quick Links". This would also make it easier for the user to consult other similar pages and overall increase his use of the wiki.
- I suggest adding a "view change" link next to the last modification date. This will provide non-experienced users with quick access to modifications in case they don't know what the "History" tab does.
- I think it would be better if we had tags under the title. I agree people will most likely add tags after they have read the content. However tags may also be used to find similar information that users can skim through while reading the current article. (e.g.: I am reading an article about a Beatles album on a wiki. As soon as I open the page I will click on “The Beatles” tag under the title and open it in a new tab in order to find out more about their other albums. I will be reading these pages in parallel and making comparisons). As an alternative we could have a tag list/cloud in the right panel.
Skin: WYSIWYG
The preview button at the bottom of the page should be the first button, as the user is likely to click on it a few times before he saves and publishes the content.
Skin: View->History
I think the "previous page" button should be in front of the first page, while the "next page" button should stay after the 9th page. This is a system users are already familiar with.
Hope this is useful ;-)
Marius Dumitru Florea wrote:
Hi Silvia,
The two words are in fact links to two different things:
* Administration: link to the wiki administration page * Administrator: link to the profile of the currently logged in user
Your comment proves that:
* it's not clear that they are links * it's not clear that they are separated
We should definitely improve this.
Marius
Hi Marius, Giving my incipient familiarity with the skin my first impressions were: * Administration -> not a link, but an indication as to were administrative activities may be performed * Administrator -> the actual link to the administration page OR link to the profile of the currently logged in user I believe this is a confusion that could affect our users as well, so having more descriptive and less alike terms would be better. Silvia -- View this message in context: http://n2.nabble.com/Proposal-XWiki-2-0-Skin-tp3405623p3486523.html Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hi Silvia,
Silvia Rusu wrote:
Ecaterina Valica-2 wrote:
Hi devs,
You can see the proposal for the new skin at http://incubator.myxwiki.org/xwiki/bin/view/Improvements/Skin20P1 Comments, opinions and implementation help are welcomed :)
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi,
Since part of my new job is to provide suggestions regarding usability matters I thought as a start I might provide some observations on the new skin :-)
First of all I like the new skin a lot. It's minimalistic and the content is organized so the users can make the most of it. The following is a list of suggestions that I think would make the user experience even better. The user I am referring to is not the web-savvy kind, but a user with a minimal browsing experience.
Skin: View->Content
- It would be great if there was a link where people who had trouble with the wiki could go for help. This could be a link to all documentation, the user guide, etc.
- "Query" is a term users that are not internet-savvy may not understand. I suggest writing "Search" in the search box. This would make "Search my wiki" redundant, so I suggest removing the text above the search box altogether.
- Users may not be familiar with some of the languages the wiki is available in. As a result they may fail to identify the current language if it is not marked distinctively (e.g. Current language could be a blue button).
- The terms "Administration Administrator" at the top of the page are redundant and may cause confusion. Users may not understand why the word is repeated. I suggest replacing "Administration" with "Loged-in as".
The two words are in fact links to two different things:
* Administration: link to the wiki administration page * Administrator: link to the profile of the currently logged in user
Your comment proves that:
* it's not clear that they are links * it's not clear that they are separated
We should definitely improve this.
Marius
I see two solutions here: 1. Use icons (administration icon and profile icon) 2. For the user full name, we could add a "You are FirstName LastName" and eventually increase the space between the two links. Raluca.
- While the first 3 actions in the âViewâ menu (Content, Source, History) are connected, I think "Related Pages" would make more sense in "Quick Links". This would also make it easier for the user to consult other similar pages and overall increase his use of the wiki.
- I suggest adding a "view change" link next to the last modification date. This will provide non-experienced users with quick access to modifications in case they don't know what the "History" tab does.
- I think it would be better if we had tags under the title. I agree people will most likely add tags after they have read the content. However tags may also be used to find similar information that users can skim through while reading the current article. (e.g.: I am reading an article about a Beatles album on a wiki. As soon as I open the page I will click on âThe Beatlesâ tag under the title and open it in a new tab in order to find out more about their other albums. I will be reading these pages in parallel and making comparisons). As an alternative we could have a tag list/cloud in the right panel.
Skin: WYSIWYG
The preview button at the bottom of the page should be the first button, as the user is likely to click on it a few times before he saves and publishes the content.
Skin: View->History
I think the "previous page" button should be in front of the first page, while the "next page" button should stay after the 9th page. This is a system users are already familiar with.
Hope this is useful ;-)
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Raluca.
Lol. The best the UX is taken in account for the admin, the best he will like XWiki. Yet, be carefull of not impacting to much the general users design just for something only the admin will see. ^_^ 2009/8/21 Ecaterina Valica <[email protected]>:
Thanks Silvia for all your feedback. I will take it into account. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Thibaut, On Fri, Aug 21, 2009 at 8:50 PM, Thibaut DEVERAUX < [email protected]> wrote:
Lol. The best the UX is taken in account for the admin, the best he will like XWiki. Yet, be carefull of not impacting to much the general users design just for something only the admin will see. ^_^
We'll definitely be working on improving XWiki's interface for all types of users (readers, content editors, wiki gardeners, power users, admins and developers) in the XE 2.1 timeframe. However right now we're keeping the modifications minimal in order to be able to ship something on time for XE 2.0 . I'll talk with Caty so that we setup a space on dev.xwiki.org to gather UX feedback and ideas. I wrote personas for various types of XWiki users back in November 2008, I'll publish them there. Thanks for your feedback, Guillaume
2009/8/21 Ecaterina Valica <[email protected]>:
Thanks Silvia for all your feedback. I will take it into account. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi Guillaume Nice ! Don't worry, making UX propositions is always faster than developping. However the more there is UX propositions, the more they develop in an interative way and the more they are a good quality. So don't worry if some UX propositions cannot be maid on time. Having a space on the wiki to store and retrieve the propositions is an exellent idea ! Have a nice day. Thibaut 2009/8/22 Guillaume Lerouge <[email protected]>:
Hi Thibaut,
On Fri, Aug 21, 2009 at 8:50 PM, Thibaut DEVERAUX < [email protected]> wrote:
Lol. The best the UX is taken in account for the admin, the best he will like XWiki. Yet, be carefull of not impacting to much the general users design just for something only the admin will see. ^_^
We'll definitely be working on improving XWiki's interface for all types of users (readers, content editors, wiki gardeners, power users, admins and developers) in the XE 2.1 timeframe. However right now we're keeping the modifications minimal in order to be able to ship something on time for XE 2.0 .
I'll talk with Caty so that we setup a space on dev.xwiki.org to gather UX feedback and ideas. I wrote personas for various types of XWiki users back in November 2008, I'll publish them there.
Thanks for your feedback,
Guillaume
2009/8/21 Ecaterina Valica <[email protected]>:
Thanks Silvia for all your feedback. I will take it into account. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (12)
-
[Ricardo Rodriguez] Your EPEC Network ICT Team -
Ecaterina Valica -
Guillaume Lerouge -
Jean-Vincent Drean -
Marius Dumitru Florea -
Niels Mayer -
Raluca Stavro -
Sergiu Dumitriu -
Silvia Rusu -
Thibaut DEVERAUX -
ThibautDeveraux
-
Vincent Massol