7 Aug
2009
7 Aug
'09
7:13 p.m.
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
7 Aug
7 Aug
7:19 p.m.
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
7:20 p.m.
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
7:21 p.m.
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
7:35 p.m.
Hi,
On Fri, Aug 7, 2009 at 7:21 PM, Vincent Massol <vincent(a)massol.net> wrote:
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.
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.
_______________________________________________
devs mailing list
devs(a)xwiki.org
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/
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:
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.
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
9:29 p.m.
Vincent Massol wrote:
On Aug 7, 2009, at 7:13 PM, Ecaterina Valica wrote:
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/
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
9:50 p.m.
On Aug 7, 2009, at 9:29 PM, Sergiu Dumitriu wrote:
Vincent Massol 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 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+…
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.
On Aug 7, 2009, at 7:13 PM, Ecaterina Valica
wrote:
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. 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 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.
10:20 p.m.
Vincent Massol wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Aug 7, 2009, at 9:29 PM, Sergiu Dumitriu wrote:
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".
Vincent Massol 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 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+…
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/ On Aug 7, 2009, at 7:13 PM, Ecaterina Valica
wrote:
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. 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 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.
10:27 p.m.
On Aug 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
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
On Aug 7, 2009, at 9:29 PM, Sergiu Dumitriu
wrote:
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".
Vincent Massol 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 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+…
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/ 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. 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.
10 Aug
10 Aug
11:11 a.m.
Hi,
On Fri, Aug 7, 2009 at 10:27 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote:
http://laurent.myxwiki.org/xwiki/bin/view/ModificationVM/
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...
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+…
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 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? 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
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
>> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
1:06 p.m.
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? 
1:38 p.m.
On Mon, Aug 10, 2009 at 1:06 PM, Ecaterina Valica<valicac(a)gmail.com> wrote:
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.
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.
4:19 p.m.
Ecaterina Valica wrote:
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/
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?
4:28 p.m.
Hi,
On Mon, Aug 10, 2009 at 4:19 PM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Ecaterina Valica wrote:
I agree with Sergiu. It blocks the information and makes it in small little
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
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? 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/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
16 Aug
16 Aug
11:54 a.m.
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.
12:01 p.m.
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.
12:48 p.m.
Sorry 3 mail...
I missed the last post. about this skin :
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposa…
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.
19 Aug
19 Aug
12:12 p.m.
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.
2:04 p.m.
Nice !
I can't wait to see it. ;-)
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.
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.
2:19 p.m.
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
<thibaut.deveraux(a)gmail.com>wrote;wrote:
Nice !
I can't wait to see it. ;-)
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> 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.
6:37 p.m.
Thanks.
Where can I find the svg files in the futur ?
2009/8/19 Ecaterina Valica <valicac(a)gmail.com>om>:
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
<thibaut.deveraux(a)gmail.com>wrote;wrote:
Nice !
I can't wait to see it. ;-)
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
> 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.
7:29 p.m.
Sorry, we currently don't have a especially place for SVG files. :)
On Wed, Aug 19, 2009 at 18:37, Thibaut DEVERAUX
<thibaut.deveraux(a)gmail.com>wrote;wrote:
Thanks.
Where can I find the svg files in the futur ?
2009/8/19 Ecaterina Valica <valicac(a)gmail.com>om>:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
<thibaut.deveraux(a)gmail.com>wrote;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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:10 p.m.
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
10 Aug
10 Aug
1 p.m.
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+…
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.
1:06 p.m.
On Aug 10, 2009, at 1:00 PM, Ecaterina Valica wrote:
I agree.
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
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+…
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.
1:52 p.m.
Vincent Massol wrote:
On Aug 10, 2009, at 1:00 PM, Ecaterina Valica wrote:
I agree.
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/
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+…
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.
6:29 p.m.
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+…
- 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/conte…
Proposal 2:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conte…
6:35 p.m.
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
I like it. What is under the Show menu now?
Thanks
-Vincent
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+…
- 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/conte…
Proposal 2:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conte…
6:43 p.m.
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 <vincent(a)massol.net> wrote:
On Aug 10, 2009, at 6:29 PM, Ecaterina Valica wrote:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conte…
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+…
- 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:
Proposal 2:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conte…
I like it. What is under the Show menu now?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:56 p.m.
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 <vincent(a)massol.net>
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+…
>>>
>>> - 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/conte…
>> Proposal 2:
>>
>
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conte…
>
> I like it. What is under the Show menu now?
>
> Thanks
> -Vincent
7:11 p.m.
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 <vincent(a)massol.net> 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 <vincent(a)massol.net>
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+…
>>>
>>> - 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/conte…
>> Proposal 2:
>>
>
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conte…
>
> I like it. What is under the Show menu now?
>
> Thanks
> -Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11 Aug
11 Aug
12:08 a.m.
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
12:43 a.m.
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
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,
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.
10:44 a.m.
Hi,
On Tue, Aug 11, 2009 at 12:43 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
[Ricardo Rodriguez] Your EPEC Network ICT Team wrote:
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
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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
6:02 p.m.
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/conte…
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 <guillaume(a)xwiki.com>wrote;wrote:
Hi,
On Tue, Aug 11, 2009 at 12:43 AM, Sergiu Dumitriu <sergiu(a)xwiki.com>
wrote:
[Ricardo Rodriguez] Your EPEC Network ICT Team
wrote:
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
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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:10 p.m.
Hi,
On Tue, Aug 11, 2009 at 6:02 PM, Ecaterina Valica <valicac(a)gmail.com> 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/conte…
a Marta & me effort ):
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/conte…
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 <guillaume(a)xwiki.com
I like contentLinks2.png best too. I agree with Sergiu on keeping the same
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
wrote:
Hi,
On Tue, Aug 11, 2009 at 12:43 AM, Sergiu Dumitriu <sergiu(a)xwiki.com>
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.
color for all links + having the number of
comments / attachments is nice
too.
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12 Aug
12 Aug
6:33 p.m.
View History Mockup
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageV…
7:04 p.m.
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
View History Mockup
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageV…
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
7:58 p.m.
Related Pages Mockup
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageV…
We should display the footer with the Tags and Creator also on History and
Related Pages?
8:06 p.m.
Hi,
On Wed, Aug 12, 2009 at 7:04 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
There's no technical reason why we couldn't use an AJAX call here too and
avoid reloading the whole page, is there?
View History Mockup
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageV…
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.
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
14 Aug
14 Aug
7:20 p.m.
Hi,
Because of the time constrain the skin might end up looking like this
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposa…
Thanks,
Caty
On Wed, Aug 12, 2009 at 20:06, Guillaume Lerouge <guillaume(a)xwiki.com>wrote;wrote:
Hi,
On Wed, Aug 12, 2009 at 7:04 PM, Vincent Massol <vincent(a)massol.net>
wrote:
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageV…
View History Mockup
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
18 Aug
18 Aug
12:44 p.m.
Hi,
Because of the time constrain the skin might end up looking like this
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposa…
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
<guillaume(a)xwiki.com>wrote;wrote:
Hi,
On Wed, Aug 12, 2009 at 7:04 PM, Vincent Massol <vincent(a)massol.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageV…
View History Mockup
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:55 p.m.
Hi,
Because of the time constrain the skin might end up looking like this
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposa…
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).
Thanks,
Caty
On Wed, Aug 12, 2009 at 20:06, Guillaume Lerouge
<guillaume(a)xwiki.com>wrote;wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi,
On Wed, Aug 12, 2009 at 7:04 PM, Vincent Massol <vincent(a)massol.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
> View History Mockup
>
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageV…
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
19 Aug
19 Aug
12:13 p.m.
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 <raluca.morosan(a)xwiki.com>wrote;wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
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/proposa…
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
> <guillaume(a)xwiki.com>wrote;wrote:
>
>> Hi,
>>
>> On Wed, Aug 12, 2009 at 7:04 PM, Vincent Massol <vincent(a)massol.net>
>> wrote:
>>
>> >
>> > On Aug 12, 2009, at 6:33 PM, Ecaterina Valica wrote:
>> >
>> > > View History Mockup
>> > >
>> >
>>
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20P1/pageV…
>
> 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
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:20 p.m.
On Tue, Aug 18, 2009 at 3:44 AM, Raluca Stavro <raluca.morosan(a)xwiki.com>wrote;wrote:
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#HPageinVi…
In
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposa…,
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
Because of the time constrain the skin might end
up looking like this
http://incubator.myxwiki.org/xwiki/bin/download/Improvements/Skin20/proposa…
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).
7 Aug
7 Aug
10:20 p.m.
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/
10:32 p.m.
On Aug 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote:
Ecaterina Valica wrote:
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 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.
10 Aug
10 Aug
11:06 a.m.
Hi,
On Fri, Aug 7, 2009 at 10:32 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Aug 7, 2009, at 10:20 PM, Sergiu Dumitriu wrote:
I think Cati is aware of this. Both links would find a position somewhere at
the top right of the skin IIRC.
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,
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
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
21 Aug
21 Aug
9:23 a.m.
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
devs(a)xwiki.org
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.
9:46 a.m.
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
devs(a)xwiki.org
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 ;-)
10:03 a.m.
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.
4:06 p.m.
Hi Silvia,
Silvia Rusu wrote:
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.
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
devs(a)xwiki.org
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 ;-)
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:50 p.m.
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 <valicac(a)gmail.com>om>:
Thanks Silvia for all your feedback. I will take it
into account.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
22 Aug
22 Aug
1:40 p.m.
Hi Thibaut,
On Fri, Aug 21, 2009 at 8:50 PM, Thibaut DEVERAUX <
thibaut.deveraux(a)gmail.com> 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 <valicac(a)gmail.com>om>:
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Thanks Silvia for all your feedback. I will take
it into account.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:52 p.m.
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 <guillaume(a)xwiki.com>om>:
Hi Thibaut,
On Fri, Aug 21, 2009 at 8:50 PM, Thibaut DEVERAUX <
thibaut.deveraux(a)gmail.com> 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 <valicac(a)gmail.com>om>:
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Thanks Silvia for all your feedback. I will take
it into account.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5557
days inactive
5572
days old
55 comments
12 participants
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