I have thrown together an interactive prototype of Flow. It's fairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/
Nothing is saved to disk. You can reply to topics or even add new ones but on refresh everything reverts to state. Right now, the "you" you are logged into is "Jorm" but I'll be adding functionality to handle that.
In the sidebar are a couple links to various "board examples":
* Fully Chaos (everything is generated randomly.) * Jimmy Wales * Maggie Dennis (Moonriddengirl) * Me * A single topic (this is what you get to if you get an echo notification)
Speaking of, if you click the echo badge, and then click on the unread notification, you'll get the experience of the user getting a reply and going to the single conversation view.
You can also click the "Feed" link and you'll be brought to your feed. The "feed" view is different from the "Board" view. The feed is private - it's all the conversations that you my be interested in or are subscribed to (have a solid star). You also see activity from the boards of *people* you're subscribed to as well, but it floats away fairly quickly if you don't subscribe to it.
Known bugs:
* The "New Topic" dialog doesn't close when you click the "X" button. No idea why; it worked the other day and now it doesn't. * Some of the conversations are threaded weird. This is an artifact of the JSON. * The tab highlights are a bit goofy.
Upcoming:
* The search functionality will work * You'll be able to add and edit tags * Stuff like archive/split/whatever * Edit your own post, etc.
Please share your thoughts.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
First off, it's really awesome to have mockups and prototypes being done in HTML/CSS/JavaScript. This prototype is really cool and fun to play with. I know there are bugs and whatnot, but you've done a great job putting this together and I look forward to seeing more prototyping like this in the future.
A couple of things jumped out at me while I used it, hopefully some of this stuff is useful and new feedback.
- The affordance for expand and collapse (a chevron symbol pointing right or down) didn't look like a control to me. I think that using symbols as buttons without outlining them is a great way to make the design lightweight, but if you make the symbol too big it looks more like a decoration and less like a control. - I think it's a good idea to be conservative about how many buttons to show, and I'm doubtful that an icon will convey "expand" or "collapse" very well, but the combined expand/collapse all button gets users into limbo states and can be a little confusing. Since items can be manually expand and collapsed, users can end up in a state where everything is expanded yet the button says "expand all". GMail uses an intermediate state for their select all button to show that you are in a partial selection state. Other interfaces often have both buttons always available. My impression is actually that this is a symptom of a larger problem (see next point). - This is not a paged interface, but users are given the ability to perform actions on "all" items. What does "all" mean in this context? If it's setup as infinite scroll then "all" is especially ambiguous. If it's paged (maybe the prototype just doesn't show the paging yet) then where are pages cut off at? - Because of the expand-in-place design, It feels labor intensive to navigate through this list. When fully expanded it's really long, and when collapsed it's tedious to get my mouse on the expand button each time to open it up, and then have to mind where the thread ends and the next begins. - There are 2 modes of access I think are most valuable; checking what's new or reading an entire thread. The way this information is organized; both directionally how topics at the top are the newest yet posts at the bottom are the newest and structurally how topics are expanded in place rather than descended into; doesn't really lend it'self particularly well to either. It either takes a lot of digging to find the bits that are new, or it takes a lot of scanning and scrolling to read a conversation. Perhaps there could be 2 ways to view this information. One, an activity list, would show what's new only, like tweets are displayed, with links to see each message in context. The other, a topic list, would have separate topic and thread views that the user moves between horizontally (similar to navigation in iOS mail.
That's all I have for now. Again, it's really awesome that this is interactive and browser-based. I'm confident the final product will be better for it.
- Trevor
On Tue, Apr 30, 2013 at 2:16 PM, Brandon Harris bharris@wikimedia.orgwrote:
I have thrown together an interactive prototype of Flow. It'sfairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/ Nothing is saved to disk. You can reply to topics or even add newones but on refresh everything reverts to state. Right now, the "you" you are logged into is "Jorm" but I'll be adding functionality to handle that.
In the sidebar are a couple links to various "board examples": * Fully Chaos (everything is generated randomly.) * Jimmy Wales * Maggie Dennis (Moonriddengirl) * Me * A single topic (this is what you get to if youget an echo notification)
Speaking of, if you click the echo badge, and then click on theunread notification, you'll get the experience of the user getting a reply and going to the single conversation view.
You can also click the "Feed" link and you'll be brought to yourfeed. The "feed" view is different from the "Board" view. The feed is private - it's all the conversations that you my be interested in or are subscribed to (have a solid star). You also see activity from the boards of *people* you're subscribed to as well, but it floats away fairly quickly if you don't subscribe to it.
Known bugs: * The "New Topic" dialog doesn't close when you click the"X" button. No idea why; it worked the other day and now it doesn't. * Some of the conversations are threaded weird. This is an artifact of the JSON. * The tab highlights are a bit goofy.
Upcoming: * The search functionality will work * You'll be able to add and edit tags * Stuff like archive/split/whatever * Edit your own post, etc. Please share your thoughts.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
a) It looks awesome! b) I generally agree with Trevor's notes. c) having a search box at the top is a GREAT idea -- this should be able to filter threads quickly and help find specific things. I use the equivalent in Gmail all the time.
A few more notes: * the collapse/expand is only available at the top level, which can make it hard to really navigate through deeply nested long conversations -- especially if you were only interested in new content * the appears-on-hover "(board * contributions)" links are hard to discover and use on a touchscreen (for instance an iPad or other tablet that gets the desktop interface by default) * I really want the entire thread title to be clickable as expand/collapse, not just the little arrow. Much easier on touch, but I also tried to click on the title portion with my mouse on my laptop. :) * The input box should probably expand to fit longer input paragraphs, if possible (at least up to some reasonable size). Right now it's hard to edit a long response. * Paging or infinite scroll need to be planned for for really long talk pages.
I agree that the "find new items" case isn't really handled well at this stage; there seems to be no "read/unread" distinction and scrolling through an entire thread to look for new things is very labor-intensive, especially on touch.
If already-seen entries were initially collapsed like in a Gmail conversation view.... a long discussion could be waaaay easier to zip through.
Separate 'list of threads' and 'list of items in a thread' may also simplify things, as Trevor suggests, when many threads are present.
-- brion
On Tue, Apr 30, 2013 at 4:05 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
First off, it's really awesome to have mockups and prototypes being done in HTML/CSS/JavaScript. This prototype is really cool and fun to play with. I know there are bugs and whatnot, but you've done a great job putting this together and I look forward to seeing more prototyping like this in the future.
A couple of things jumped out at me while I used it, hopefully some of this stuff is useful and new feedback.
- The affordance for expand and collapse (a chevron symbol pointing
right or down) didn't look like a control to me. I think that using symbols as buttons without outlining them is a great way to make the design lightweight, but if you make the symbol too big it looks more like a decoration and less like a control.
- I think it's a good idea to be conservative about how many buttons
to show, and I'm doubtful that an icon will convey "expand" or "collapse" very well, but the combined expand/collapse all button gets users into limbo states and can be a little confusing. Since items can be manually expand and collapsed, users can end up in a state where everything is expanded yet the button says "expand all". GMail uses an intermediate state for their select all button to show that you are in a partial selection state. Other interfaces often have both buttons always available. My impression is actually that this is a symptom of a larger problem (see next point).
- This is not a paged interface, but users are given the ability to
perform actions on "all" items. What does "all" mean in this context? If it's setup as infinite scroll then "all" is especially ambiguous. If it's paged (maybe the prototype just doesn't show the paging yet) then where are pages cut off at?
- Because of the expand-in-place design, It feels labor intensive to
navigate through this list. When fully expanded it's really long, and when collapsed it's tedious to get my mouse on the expand button each time to open it up, and then have to mind where the thread ends and the next begins.
- There are 2 modes of access I think are most valuable; checking
what's new or reading an entire thread. The way this information is organized; both directionally how topics at the top are the newest yet posts at the bottom are the newest and structurally how topics are expanded in place rather than descended into; doesn't really lend it'self particularly well to either. It either takes a lot of digging to find the bits that are new, or it takes a lot of scanning and scrolling to read a conversation. Perhaps there could be 2 ways to view this information. One, an activity list, would show what's new only, like tweets are displayed, with links to see each message in context. The other, a topic list, would have separate topic and thread views that the user moves between horizontally (similar to navigation in iOS mail.
That's all I have for now. Again, it's really awesome that this is interactive and browser-based. I'm confident the final product will be better for it.
- Trevor
On Tue, Apr 30, 2013 at 2:16 PM, Brandon Harris bharris@wikimedia.orgwrote:
I have thrown together an interactive prototype of Flow. It'sfairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/ Nothing is saved to disk. You can reply to topics or even addnew ones but on refresh everything reverts to state. Right now, the "you" you are logged into is "Jorm" but I'll be adding functionality to handle that.
In the sidebar are a couple links to various "board examples": * Fully Chaos (everything is generated randomly.) * Jimmy Wales * Maggie Dennis (Moonriddengirl) * Me * A single topic (this is what you get to if youget an echo notification)
Speaking of, if you click the echo badge, and then click on theunread notification, you'll get the experience of the user getting a reply and going to the single conversation view.
You can also click the "Feed" link and you'll be brought to yourfeed. The "feed" view is different from the "Board" view. The feed is private - it's all the conversations that you my be interested in or are subscribed to (have a solid star). You also see activity from the boards of *people* you're subscribed to as well, but it floats away fairly quickly if you don't subscribe to it.
Known bugs: * The "New Topic" dialog doesn't close when you click the"X" button. No idea why; it worked the other day and now it doesn't. * Some of the conversations are threaded weird. This is an artifact of the JSON. * The tab highlights are a bit goofy.
Upcoming: * The search functionality will work * You'll be able to add and edit tags * Stuff like archive/split/whatever * Edit your own post, etc. Please share your thoughts.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Wed, May 1, 2013 at 12:56 AM, Brion Vibber bvibber@wikimedia.org wrote:
I agree that the "find new items" case isn't really handled well at this stage; there seems to be no "read/unread" distinction
My understanding from talking to Brandon earlier is that unread parts of the thread have a green vertical border right now, like the comments in the first example thread in http://elohim.gaijin.com/flow/ , and the idea is to make that fade out as you scroll over them (not yet implemented).
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
This is great! in terms of chevrons I would suggest collapsing them by default. For me the fact they are open and next to a big conversation makes them less clear. It's also nice to get an overview before diving deep in.
When clicking save the text under is very wordy. I wonder if this could be collapsed somehow
Also to echo Trevor it's truly wonderful to see a working prototype - it makes the vision much clearer!
PS. Taking a mobile first approach how would this look on mobile? :) It looks like it would in current form possibly hitting problems with heavily nested lists. On 1 May 2013 00:57, "Brion Vibber" bvibber@wikimedia.org wrote:
a) It looks awesome! b) I generally agree with Trevor's notes. c) having a search box at the top is a GREAT idea -- this should be able to filter threads quickly and help find specific things. I use the equivalent in Gmail all the time.
A few more notes:
- the collapse/expand is only available at the top level, which can make
it hard to really navigate through deeply nested long conversations -- especially if you were only interested in new content
- the appears-on-hover "(board * contributions)" links are hard to
discover and use on a touchscreen (for instance an iPad or other tablet that gets the desktop interface by default)
- I really want the entire thread title to be clickable as
expand/collapse, not just the little arrow. Much easier on touch, but I also tried to click on the title portion with my mouse on my laptop. :)
- The input box should probably expand to fit longer input paragraphs, if
possible (at least up to some reasonable size). Right now it's hard to edit a long response.
- Paging or infinite scroll need to be planned for for really long talk
pages.
I agree that the "find new items" case isn't really handled well at this stage; there seems to be no "read/unread" distinction and scrolling through an entire thread to look for new things is very labor-intensive, especially on touch.
If already-seen entries were initially collapsed like in a Gmail conversation view.... a long discussion could be waaaay easier to zip through.
Separate 'list of threads' and 'list of items in a thread' may also simplify things, as Trevor suggests, when many threads are present.
-- brion
On Tue, Apr 30, 2013 at 4:05 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
First off, it's really awesome to have mockups and prototypes being done in HTML/CSS/JavaScript. This prototype is really cool and fun to play with. I know there are bugs and whatnot, but you've done a great job putting this together and I look forward to seeing more prototyping like this in the future.
A couple of things jumped out at me while I used it, hopefully some of this stuff is useful and new feedback.
- The affordance for expand and collapse (a chevron symbol pointing
right or down) didn't look like a control to me. I think that using symbols as buttons without outlining them is a great way to make the design lightweight, but if you make the symbol too big it looks more like a decoration and less like a control.
- I think it's a good idea to be conservative about how many buttons
to show, and I'm doubtful that an icon will convey "expand" or "collapse" very well, but the combined expand/collapse all button gets users into limbo states and can be a little confusing. Since items can be manually expand and collapsed, users can end up in a state where everything is expanded yet the button says "expand all". GMail uses an intermediate state for their select all button to show that you are in a partial selection state. Other interfaces often have both buttons always available. My impression is actually that this is a symptom of a larger problem (see next point).
- This is not a paged interface, but users are given the ability to
perform actions on "all" items. What does "all" mean in this context? If it's setup as infinite scroll then "all" is especially ambiguous. If it's paged (maybe the prototype just doesn't show the paging yet) then where are pages cut off at?
- Because of the expand-in-place design, It feels labor intensive to
navigate through this list. When fully expanded it's really long, and when collapsed it's tedious to get my mouse on the expand button each time to open it up, and then have to mind where the thread ends and the next begins.
- There are 2 modes of access I think are most valuable; checking
what's new or reading an entire thread. The way this information is organized; both directionally how topics at the top are the newest yet posts at the bottom are the newest and structurally how topics are expanded in place rather than descended into; doesn't really lend it'self particularly well to either. It either takes a lot of digging to find the bits that are new, or it takes a lot of scanning and scrolling to read a conversation. Perhaps there could be 2 ways to view this information. One, an activity list, would show what's new only, like tweets are displayed, with links to see each message in context. The other, a topic list, would have separate topic and thread views that the user moves between horizontally (similar to navigation in iOS mail.
That's all I have for now. Again, it's really awesome that this is interactive and browser-based. I'm confident the final product will be better for it.
- Trevor
On Tue, Apr 30, 2013 at 2:16 PM, Brandon Harris bharris@wikimedia.orgwrote:
I have thrown together an interactive prototype of Flow. It'sfairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/ Nothing is saved to disk. You can reply to topics or even addnew ones but on refresh everything reverts to state. Right now, the "you" you are logged into is "Jorm" but I'll be adding functionality to handle that.
In the sidebar are a couple links to various "board examples": * Fully Chaos (everything is generated randomly.) * Jimmy Wales * Maggie Dennis (Moonriddengirl) * Me * A single topic (this is what you get to if youget an echo notification)
Speaking of, if you click the echo badge, and then click on theunread notification, you'll get the experience of the user getting a reply and going to the single conversation view.
You can also click the "Feed" link and you'll be brought to yourfeed. The "feed" view is different from the "Board" view. The feed is private - it's all the conversations that you my be interested in or are subscribed to (have a solid star). You also see activity from the boards of *people* you're subscribed to as well, but it floats away fairly quickly if you don't subscribe to it.
Known bugs: * The "New Topic" dialog doesn't close when you clickthe "X" button. No idea why; it worked the other day and now it doesn't. * Some of the conversations are threaded weird. This is an artifact of the JSON. * The tab highlights are a bit goofy.
Upcoming: * The search functionality will work * You'll be able to add and edit tags * Stuff like archive/split/whatever * Edit your own post, etc. Please share your thoughts.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
pps. the be nice placeholder is a lovely touch. A subtle reminder of the community we want/ need to foster. On 1 May 2013 08:53, "Jon Robson" jrobson@wikimedia.org wrote:
This is great! in terms of chevrons I would suggest collapsing them by default. For me the fact they are open and next to a big conversation makes them less clear. It's also nice to get an overview before diving deep in.
When clicking save the text under is very wordy. I wonder if this could be collapsed somehow
Also to echo Trevor it's truly wonderful to see a working prototype - it makes the vision much clearer!
PS. Taking a mobile first approach how would this look on mobile? :) It looks like it would in current form possibly hitting problems with heavily nested lists. On 1 May 2013 00:57, "Brion Vibber" bvibber@wikimedia.org wrote:
a) It looks awesome! b) I generally agree with Trevor's notes. c) having a search box at the top is a GREAT idea -- this should be able to filter threads quickly and help find specific things. I use the equivalent in Gmail all the time.
A few more notes:
- the collapse/expand is only available at the top level, which can make
it hard to really navigate through deeply nested long conversations -- especially if you were only interested in new content
- the appears-on-hover "(board * contributions)" links are hard to
discover and use on a touchscreen (for instance an iPad or other tablet that gets the desktop interface by default)
- I really want the entire thread title to be clickable as
expand/collapse, not just the little arrow. Much easier on touch, but I also tried to click on the title portion with my mouse on my laptop. :)
- The input box should probably expand to fit longer input paragraphs, if
possible (at least up to some reasonable size). Right now it's hard to edit a long response.
- Paging or infinite scroll need to be planned for for really long talk
pages.
I agree that the "find new items" case isn't really handled well at this stage; there seems to be no "read/unread" distinction and scrolling through an entire thread to look for new things is very labor-intensive, especially on touch.
If already-seen entries were initially collapsed like in a Gmail conversation view.... a long discussion could be waaaay easier to zip through.
Separate 'list of threads' and 'list of items in a thread' may also simplify things, as Trevor suggests, when many threads are present.
-- brion
On Tue, Apr 30, 2013 at 4:05 PM, Trevor Parscal tparscal@wikimedia.orgwrote:
First off, it's really awesome to have mockups and prototypes being done in HTML/CSS/JavaScript. This prototype is really cool and fun to play with. I know there are bugs and whatnot, but you've done a great job putting this together and I look forward to seeing more prototyping like this in the future.
A couple of things jumped out at me while I used it, hopefully some of this stuff is useful and new feedback.
- The affordance for expand and collapse (a chevron symbol pointing
right or down) didn't look like a control to me. I think that using symbols as buttons without outlining them is a great way to make the design lightweight, but if you make the symbol too big it looks more like a decoration and less like a control.
- I think it's a good idea to be conservative about how many buttons
to show, and I'm doubtful that an icon will convey "expand" or "collapse" very well, but the combined expand/collapse all button gets users into limbo states and can be a little confusing. Since items can be manually expand and collapsed, users can end up in a state where everything is expanded yet the button says "expand all". GMail uses an intermediate state for their select all button to show that you are in a partial selection state. Other interfaces often have both buttons always available. My impression is actually that this is a symptom of a larger problem (see next point).
- This is not a paged interface, but users are given the ability to
perform actions on "all" items. What does "all" mean in this context? If it's setup as infinite scroll then "all" is especially ambiguous. If it's paged (maybe the prototype just doesn't show the paging yet) then where are pages cut off at?
- Because of the expand-in-place design, It feels labor intensive to
navigate through this list. When fully expanded it's really long, and when collapsed it's tedious to get my mouse on the expand button each time to open it up, and then have to mind where the thread ends and the next begins.
- There are 2 modes of access I think are most valuable; checking
what's new or reading an entire thread. The way this information is organized; both directionally how topics at the top are the newest yet posts at the bottom are the newest and structurally how topics are expanded in place rather than descended into; doesn't really lend it'self particularly well to either. It either takes a lot of digging to find the bits that are new, or it takes a lot of scanning and scrolling to read a conversation. Perhaps there could be 2 ways to view this information. One, an activity list, would show what's new only, like tweets are displayed, with links to see each message in context. The other, a topic list, would have separate topic and thread views that the user moves between horizontally (similar to navigation in iOS mail.
That's all I have for now. Again, it's really awesome that this is interactive and browser-based. I'm confident the final product will be better for it.
- Trevor
On Tue, Apr 30, 2013 at 2:16 PM, Brandon Harris bharris@wikimedia.orgwrote:
I have thrown together an interactive prototype of Flow. It'sfairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/ Nothing is saved to disk. You can reply to topics or even addnew ones but on refresh everything reverts to state. Right now, the "you" you are logged into is "Jorm" but I'll be adding functionality to handle that.
In the sidebar are a couple links to various "board examples": * Fully Chaos (everything is generatedrandomly.) * Jimmy Wales * Maggie Dennis (Moonriddengirl) * Me * A single topic (this is what you get to if you get an echo notification)
Speaking of, if you click the echo badge, and then click on theunread notification, you'll get the experience of the user getting a reply and going to the single conversation view.
You can also click the "Feed" link and you'll be brought toyour feed. The "feed" view is different from the "Board" view. The feed is private - it's all the conversations that you my be interested in or are subscribed to (have a solid star). You also see activity from the boards of *people* you're subscribed to as well, but it floats away fairly quickly if you don't subscribe to it.
Known bugs: * The "New Topic" dialog doesn't close when you clickthe "X" button. No idea why; it worked the other day and now it doesn't. * Some of the conversations are threaded weird. This is an artifact of the JSON. * The tab highlights are a bit goofy.
Upcoming: * The search functionality will work * You'll be able to add and edit tags * Stuff like archive/split/whatever * Edit your own post, etc. Please share your thoughts.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Wed, May 1, 2013 at 12:53 AM, Jon Robson jrobson@wikimedia.org wrote:
Also to echo Trevor it's truly wonderful to see a working prototype - it makes the vision much clearer!
I gave Jorm some feedback offlist, but also wanted to say that high-fidelity/interactive prototypes make a world of difference. Kudos.
I'm responding to everybody in this single mail, but first:
There is a new version at http://elohim.gaijin.com/flow/
This is what's changed:
* Posts are automatically marked read as you scroll through them. * Unread posts are significantly called out (green headers, experimental - this is fairly obnoxious but you are warned) * Topic titles are now hot * Rudimentary search functionality - Loading throbber - case insensitive - DOES NOT tokenize - searches titles, authornames, tags, postcontent * Clicking the gear icon now brings up a menu * Clicking the subscribe/unsubscribe stars now do things * Clicking the tag icon now opens a small dialog (that doesn't work yet); * Reply form auto-focuses to the textarea now.
On Apr 30, 2013, at 4:05 PM, Trevor Parscal tparscal@wikimedia.org wrote:
First off, it's really awesome to have mockups and prototypes being done in HTML/CSS/JavaScript. This prototype is really cool and fun to play with. I know there are bugs and whatnot, but you've done a great job putting this together and I look forward to seeing more prototyping like this in the future.
A couple of things jumped out at me while I used it, hopefully some of this stuff is useful and new feedback. • The affordance for expand and collapse (a chevron symbol pointing right or down) didn't look like a control to me. I think that using symbols as buttons without outlining them is a great way to make the design lightweight, but if you make the symbol too big it looks more like a decoration and less like a control.
I agree; I went with chevrons because they are used in mobile for section expansion and I thought that having a similar theme would be useful. The first ones I used were . . . "fatter". . . but they felt clunky and blocky so we've got this.
Right now, I've made the entire title "hot" as well so as to increase the affordance size. They should also probably have a hover state to indicate that something is going to happen.
I'm absolutely open for better ideas.
• I think it's a good idea to be conservative about how many buttons to show, and I'm doubtful that an icon will convey "expand" or "collapse" very well, but the combined expand/collapse all button gets users into limbo states and can be a little confusing. Since items can be manually expand and collapsed, users can end up in a state where everything is expanded yet the button says "expand all". GMail uses an intermediate state for their select all button to show that you are in a partial selection state. Other interfaces often have both buttons always available. My impression is actually that this is a symptom of a larger problem (see next point).
The "Collapse all" button is actually there for ease-of-use in the prototype. I'm not really thinking it should make it into the final product because, as you said, the concept of "all" doesn't make a lot of sense in the context of a lazy-loaded, infinitely scrolling discussion system.
On Apr 30, 2013, at 4:56 PM, Brion Vibber bvibber@wikimedia.org wrote:
A few more notes:
- the collapse/expand is only available at the top level, which can make it hard to really navigate through deeply nested long conversations -- especially if you were only interested in new content
So, this is what LiquidThreads does, and maybe we should revisit it. I worry, though, that having *too* many controls will be difficult to handle.
One possible solution to this (which I will prototype up) is to:
a) Automatically collapse read "branches" b) Only provide a control to *expand* those posts (and it would expand all posts in the branch (so you don't have to do the horrible Quora style "click to open each comment)
- the appears-on-hover "(board * contributions)" links are hard to discover and use on a touchscreen (for instance an iPad or other tablet that gets the desktop interface by default)
Jah. Erik asked that I provide minimal information and only do selective reveal, which isn't mobile-first but we're trying to illustrate concepts here rather than final functionality.
- I really want the entire thread title to be clickable as expand/collapse, not just the little arrow. Much easier on touch, but I also tried to click on the title portion with my mouse on my laptop. :)
Done.
- The input box should probably expand to fit longer input paragraphs, if possible (at least up to some reasonable size). Right now it's hard to edit a long response.
I'm doing some experiments with auto-sizing textareas but I'm not happy with anything I've gotten so far.
- Paging or infinite scroll need to be planned for for really long talk pages.
Infinite scroll is the Plan™.
I agree that the "find new items" case isn't really handled well at this stage; there seems to be no "read/unread" distinction and scrolling through an entire thread to look for new things is very labor-intensive, especially on touch.
See above comment about collapsing.
Right now, I'm using a very obnoxious green header for each unread post. I do not expect this to last, but you DEFINITELY know if it's read or not.
On Apr 30, 2013, at 5:06 PM, Erik Moeller erik@wikimedia.org wrote:
My understanding from talking to Brandon earlier is that unread parts of the thread have a green vertical border right now, like the comments in the first example thread in http://elohim.gaijin.com/flow/ , and the idea is to make that fade out as you scroll over them (not yet implemented).
This is now implemented, but I'm not sure of the "action" yet. I'm using a library called "waypoints" and it works but there are lots of variables we can tweak.
On Apr 30, 2013, at 10:02 PM, Maryana Pinchuk mpinchuk@wikimedia.org wrote:
On a more general note, I'm still not sure I grok the board/feed distinction – I was thinking that new stuff would appear in your feed, and all stuff you follow would appear in your board, but that doesn't look to be the case.
More like the opposite:
Feed: Stuff you follow Board: Stuff about you and your activity
This is also a big problem I have with the concept behind LiquidThreads – if I'm already following pages on my watchlist, which is kind of my de facto feed, I really don't want to visit a separate "new messages" page unless it actually shows me a roll-up of all new messages related to those pages (as opposed to basically the full threads of three-year-old discussions, with one or two new messages buried somewhere in the middle). I'm also not sure how the watchlist is going to interact with Flow, given that, in essence, it's serving many of the user needs that Flow is trying to solve for (albeit in a weird, suboptimal way) at the moment. Have you done any thinking about how to delineate these features more clearly?
Lastly, the feed/board distinction (if I'm understanding it correctly) seems much more useful for when all discussions (village pumps, articles, the glorious future when messaging goes cross-project...) are Flow-enabled, not just user talk. Then there's an obvious need for seeing the stuff I may be semi-passively following from various scattered discussions on one view, and having a separate view for really important stuff directed specifically at me. Having two different views for just user-to-user messaging, though, feels too heavy to me. Why not just one for now?
Actually, the feed solves for two very distinct use cases that are not addressed by the board:
1) Conversations occurring across multiple talk pages 2) Tracking conversations that you are involved in on other people's talk pages
While I had originally spent a lot of thought on the "single board, two viewpoints" solution, in the end having a board/feed model made more sense to me because:
1) User talk pages already *kind of* match the "board" model (and mapping contributions into it isn't that much of a leap) 2) Most people are used to the concept of "my stuff" versus "the stuff I'm following", even if there are many ways this is done: Facebook has a "Profile" and a "Feed" Twitter has a "Profile" and a "Stream" LiveJournal has a "Journal" and a "Friends Page" etc. 3) We can probably roll out easier. We give *all* users a Feed, but then users can selectively "upgrade" their talk pages to "Boards". This gives users flexibility as to when they move into the Bright Future.
On May 1, 2013, at 12:53 AM, Jon Robson jrobson@wikimedia.org wrote:
When clicking save the text under is very wordy. I wonder if this could be collapsed somehow
This is a requirement from legal. There's no real way around it.
pps. the be nice placeholder is a lovely touch. A subtle reminder of the community we want/ need to foster.
Kind-of-not-quite "accidental". :)
On May 1, 2013, at 4:01 AM, Mathieu Stumpf psychoslave@culture-libre.org wrote:
When you click reply, you should directly have the textfield focused. Also within the textfield pressing tab should let you switch to the save button, then the cancel button, with a highlight which let user know which element is focused.
I've got the textarea focusing but there's some goofiness I ran into with handling tabindex on the other elements. I'll see what I can do about it but at the end of the day this is only about half as powerful as it will be when it is truly backed by a server-side system.
Always reducing the box with a bigger left margin is not great for very deap threads. I have no perfect solution to give instead those said. Maybe having a "box-min-size" test that will change the comportement when reached, for example you may go back to a bigger box but with a right margin and using right box borders to let users follow the flow.
Right now, I'm not applying any logic to how deep the branches can go. I've got an exhaustive analysis of branch depths located at mw:Flow Portal someplace; I think the final layout is going to be "branch in for 4 levels, and then go 'flat'" but I wanted to get it out in an easy state first.
Applying this kind of functionality WILL have an effect on the conversation style and norms but I don't think that's a bad thing.
I think tags/subscribe/other icons should be more spaced.
This should be easy to do.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Wed, May 1, 2013 at 2:50 PM, Brandon Harris bharris@wikimedia.orgwrote:
* Posts are automatically marked read as you scrollthrough them. * Unread posts are significantly called out (green headers, experimental - this is fairly obnoxious but you are warned)
I kinda like it. :)
* Topic titles are now hot
\o/ yay :D
* Rudimentary search functionality - Loading throbber - case insensitive - DOES NOT tokenize - searches titles, authornames, tags, postcontent
In Firefox and Chromium this is giving me an error: Cannot call method 'match' of null
Right now, I've made the entire title "hot" as well so as to
increase the affordance size. They should also probably have a hover state to indicate that something is going to happen. ...
One possible solution to this (which I will prototype up) is to:
a) Automatically collapse read "branches" b) Only provide a control to *expand* those posts (and itwould expand all posts in the branch (so you don't have to do the horrible Quora style "click to open each comment)
I think Gmail is a very good model to follow -- they've put a lot of effort into making a good system that handles long discussions, with collapsing of already-read items but it's easy to click through to open them and see more context.
They don't use a hover effect other than the cursor switching to the hand pointer. There's no chevrons, just click the title to expand or collapse.
- the appears-on-hover "(board * contributions)" links are hard to
discover and use on a touchscreen (for instance an iPad or other tablet that gets the desktop interface by default)
Jah. Erik asked that I provide minimal information and only doselective reveal, which isn't mobile-first but we're trying to illustrate concepts here rather than final functionality.
I think my preference is to have a fairly standard "user block" that expands on click to provide other links. Hover color/border change and/or exposure arrows could provide an affordance here.
-- brion
On May 1, 2013, at 3:25 PM, Brion Vibber bvibber@wikimedia.org wrote:
I think Gmail is a very good model to follow -- they've put a lot of effort into making a good system that handles long discussions, with collapsing of already-read items but it's easy to click through to open them and see more context.
Yeah, I'm trying to get there but the way the HTML is generated makes something like this a SERIOUS pain in the ass.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On May 1, 2013, at 3:25 PM, Brion Vibber bvibber@wikimedia.org wrote:
* Rudimentary search functionality - Loading throbber - case insensitive - DOES NOT tokenize - searches titles, authornames, tags, postcontentIn Firefox and Chromium this is giving me an error: Cannot call method 'match' of null
Should be fixed (s/taglist/.taglist/);
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hello!
I have released a new version of the Flow prototype into the wild. This will be the version that is discussed during office hours tomorrow.
The URL for the prototype has moved. It is now located at:
http://unicorn.wmflabs.org/flow/
I have also created a page that explains what the prototype is and how to use it. I will be updating the release notes there from now on and not posting to this list, so you should watch this page for changes:
http://www.mediawiki.org/wiki/Flow_Portal/lnteractive_Prototype
I'll include the latest release notes, though (mirrored on the mw.org page):
=== May 9, 2013 === * Read posts are now only collapsed in the Feed views * The "+Topic" button now reads "+New Message" * Hide the "New message" button when in feed view * Tag actions no longer work on unsubscribed topics * Author metadata (edit count, etc.) can now be hidden from a tool in the sidebar * Posts by yourself now have a blue border instead of grey (h/t to TheDJ) * Added in a "mention" example to the Echo flyout. * Cleaned up the json file for Jimmy Wales' board with regard to post depths. * "Reply" buttons changed to mw-ui-constructive (green) * Changed the green color of unread posts to match the reply button color (avoid clashing) * Going to a "Feed" view now removes any tabs. Returning to a board shows the tabs again. * Taglist section no longer displays if there are no tags * In Feed view, topics on own board no longer include your username * In Feed view, the sort of topics is NOT based on "last update time". Instead: ** Topics that you are ''subscribed'' to are sorted by last update time; ** Topics that you are ''not'' subscribed to are sorted by create time. *** This more accurately reflects the behavior when you are subscribed to a user but not every topic on their board * Added a new sidebar section, "Back and Forths" ** This gives you a "masquerade" view, so that you can see what the same topic will look like from the viewpoints of different users. *** The first is ''your'' view. *** The second and third are the views of two other participants. * In Board view, all topics are expanded by default (for easier fast-scanning) * Individual posts can be flagged as "abusive". This is the beginnings of a workflow; actual anti-vandalism functionality will require more work. * Removed the "Jorm Board" - it was a redundant view
=== May 4, 2013 === * Read posts in any thread are collapsed by default, with an indicator to open all of them up. ** Posts are not collapsed if the thread is collapsed ** Collapse sections is an all-or-nothing deal ** You cannot "re-collapse" read posts. Adding a control to every post is too heavy ** Collapsing a thread will uncollapse all posts inside of it and remove the indicator *** Reopening the thread will expand all posts * On start up, a modal appears asking you for your user name. ** The form saves it and operates as "that person" from then on. ** This is saved to a cookie, which prevents the modal from opening in the future **There is a "clear saved username" link on the side. * The feed link now treats itself as if it were the "logged in" user and does some replacing on text to imply that the conversations are happening with them (and not the original owner of the posts)
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
As McDonald's says, I'm lovin' it!
My main complaint is that I'm not sure if indented threading is the way to go; we know we end up with reallly deep conversation threads on these things, and it gets hard to read a few levels in. Pre-collapsing already-read parts of the thread should help a lot in common circumstances, but if you expand it you don't want it esploding.
-- brion
On Wed, May 8, 2013 at 10:36 PM, Brandon Harris bharris@wikimedia.orgwrote:
Hello! I have released a new version of the Flow prototype into the wild.This will be the version that is discussed during office hours tomorrow.
The URL for the prototype has moved. It is now located at: http://unicorn.wmflabs.org/flow/ I have also created a page that explains what the prototype is andhow to use it. I will be updating the release notes there from now on and not posting to this list, so you should watch this page for changes:
http://www.mediawiki.org/wiki/Flow_Portal/lnteractive_Prototype
I'll include the latest release notes, though (mirrored on themw.org page):
=== May 9, 2013 ===
- Read posts are now only collapsed in the Feed views
- The "+Topic" button now reads "+New Message"
- Hide the "New message" button when in feed view
- Tag actions no longer work on unsubscribed topics
- Author metadata (edit count, etc.) can now be hidden from a tool in the
sidebar
- Posts by yourself now have a blue border instead of grey (h/t to TheDJ)
- Added in a "mention" example to the Echo flyout.
- Cleaned up the json file for Jimmy Wales' board with regard to post
depths.
- "Reply" buttons changed to mw-ui-constructive (green)
- Changed the green color of unread posts to match the reply button color
(avoid clashing)
- Going to a "Feed" view now removes any tabs. Returning to a board shows
the tabs again.
- Taglist section no longer displays if there are no tags
- In Feed view, topics on own board no longer include your username
- In Feed view, the sort of topics is NOT based on "last update time".
Instead: ** Topics that you are ''subscribed'' to are sorted by last update time; ** Topics that you are ''not'' subscribed to are sorted by create time. *** This more accurately reflects the behavior when you are subscribed to a user but not every topic on their board
- Added a new sidebar section, "Back and Forths"
** This gives you a "masquerade" view, so that you can see what the same topic will look like from the viewpoints of different users. *** The first is ''your'' view. *** The second and third are the views of two other participants.
- In Board view, all topics are expanded by default (for easier
fast-scanning)
- Individual posts can be flagged as "abusive". This is the beginnings of
a workflow; actual anti-vandalism functionality will require more work.
- Removed the "Jorm Board" - it was a redundant view
=== May 4, 2013 ===
- Read posts in any thread are collapsed by default, with an indicator to
open all of them up. ** Posts are not collapsed if the thread is collapsed ** Collapse sections is an all-or-nothing deal ** You cannot "re-collapse" read posts. Adding a control to every post is too heavy ** Collapsing a thread will uncollapse all posts inside of it and remove the indicator *** Reopening the thread will expand all posts
- On start up, a modal appears asking you for your user name.
** The form saves it and operates as "that person" from then on. ** This is saved to a cookie, which prevents the modal from opening in the future **There is a "clear saved username" link on the side.
- The feed link now treats itself as if it were the "logged in" user and
does some replacing on text to imply that the conversations are happening with them (and not the original owner of the posts)
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On May 9, 2013, at 9:51 AM, Brion Vibber bvibber@wikimedia.org wrote:
My main complaint is that I'm not sure if indented threading is the way to go; we know we end up with reallly deep conversation threads on these things, and it gets hard to read a few levels in. Pre-collapsing already-read parts of the thread should help a lot in common circumstances, but if you expand it you don't want it esploding.
I've been thinking a lot about this and wrote up several ideas here, including my corollary to Godwin's Law:
http://www.mediawiki.org/wiki/Flow_Portal/User_to_User_Discussions#Thread_De...
Currently, I'm not restricting depth but I think we should after 4 levels.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Should we restrict depth? Perhaps, it's better to limit the number of levels expanded at one time (when the user presses "expand" button). LiveJournal is very uncomfortable in this case: after you click "expand" it expands all inner conversations at every level.
On Thu, May 9, 2013 at 8:04 PM, Brandon Harris bharris@wikimedia.orgwrote:
On May 9, 2013, at 9:51 AM, Brion Vibber bvibber@wikimedia.org wrote:
My main complaint is that I'm not sure if indented threading is the way
to go; we know we end up with reallly deep conversation threads on these things, and it gets hard to read a few levels in. Pre-collapsing already-read parts of the thread should help a lot in common circumstances, but if you expand it you don't want it esploding.
I've been thinking a lot about this and wrote up several ideashere, including my corollary to Godwin's Law:
http://www.mediawiki.org/wiki/Flow_Portal/User_to_User_Discussions#Thread_De...
Currently, I'm not restricting depth but I think we should after 4levels.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Forcing folks to have to click something to expand the rest of the conversation can be very annoying and cumbersome, however. Given that the important part of the discussion tends to be the end of it, it would be particularly problematic to hide it.
On 09/05/13 18:11, Paul Selitskas wrote:
Should we restrict depth? Perhaps, it's better to limit the number of levels expanded at one time (when the user presses "expand" button). LiveJournal is very uncomfortable in this case: after you click "expand" it expands all inner conversations at every level.
On Thu, May 9, 2013 at 8:04 PM, Brandon Harris <bharris@wikimedia.org mailto:bharris@wikimedia.org> wrote:
On May 9, 2013, at 9:51 AM, Brion Vibber <bvibber@wikimedia.org <mailto:bvibber@wikimedia.org>> wrote: > My main complaint is that I'm not sure if indented threading is the way to go; we know we end up with reallly deep conversation threads on these things, and it gets hard to read a few levels in. Pre-collapsing already-read parts of the thread should help a lot in common circumstances, but if you expand it you don't want it esploding. I've been thinking a lot about this and wrote up several ideas here, including my corollary to Godwin's Law: http://www.mediawiki.org/wiki/Flow_Portal/User_to_User_Discussions#Thread_Depth_Models Currently, I'm not restricting depth but I think we should after 4 levels. --- Brandon Harris, Senior Designer, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate _______________________________________________ Design mailing list Design@lists.wikimedia.org <mailto:Design@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/design-- З павагай, Павел Селіцкас/Pavel Selitskas Wizardist @ Wikimedia projects
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Thu, 09 May 2013 19:04:19 +0200, Brandon Harris bharris@wikimedia.org wrote:
Currently, I'm not restricting depth but I think we should after 4 levels.
Couldn't we restrict it visually, allowing replies that are technically nested, but graphically "flat"? They could feature some sort of backwards-arrow icon with tooltip to inform the reader this happened. This way we'd get the best of both worlds.
Alternatively, we could indent every reply after, say, fourth one, with a progressively smaller "tab", so that the left edges would form a curve.
On Thu, May 9, 2013 at 1:21 PM, Bartosz Dziewoński matma.rex@gmail.comwrote:
Couldn't we restrict it visually, allowing replies that are technically nested, but graphically "flat"?
This is an interesting idea. It's perhaps possible for the nesting of replies to be infinite, and then we configure the indenting to only show however much we want?
I can't avoid mentioning this current technique to "shift" the discussion back and continuing nesting at the same time:
https://en.wikipedia.org/wiki/Template:Outdent
On Thu, May 9, 2013 at 11:45 PM, Steven Walling swalling@wikimedia.orgwrote:
On Thu, May 9, 2013 at 1:21 PM, Bartosz Dziewoński matma.rex@gmail.comwrote:
Couldn't we restrict it visually, allowing replies that are technically nested, but graphically "flat"?
This is an interesting idea. It's perhaps possible for the nesting of replies to be infinite, and then we configure the indenting to only show however much we want?
-- Steven Walling https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
That's actually how it would be implemented, and it has at least been written up somewhere in the voluminous documents.
The reason for continuing to record reply-to ids is so that if you split out a section into a new topic, it will retain the response tree correctly.
On May 9, 2013, at 1:21 PM, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Thu, 09 May 2013 19:04:19 +0200, Brandon Harris bharris@wikimedia.org wrote:
Currently, I'm not restricting depth but I think we should after 4 levels.
Couldn't we restrict it visually, allowing replies that are technically nested, but graphically "flat"? They could feature some sort of backwards-arrow icon with tooltip to inform the reader this happened. This way we'd get the best of both worlds.
Alternatively, we could indent every reply after, say, fourth one, with a progressively smaller "tab", so that the left edges would form a curve.
-- Matma Rex
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On Thu, 09 May 2013 23:11:43 +0200, Brandon Harris bharris@wikimedia.org wrote:
That's actually how it would be implemented, and it has at least been written up somewhere in the voluminous documents.
Which one of the ways I mentioned is "that" way? :) (Genuinely interested.)
On Wed, May 1, 2013 at 2:50 PM, Brandon Harris bharris@wikimedia.orgwrote:
I'm responding to everybody in this single mail, but first: There is a new version at http://elohim.gaijin.com/flow/ This is what's changed: * Posts are automatically marked read as you scrollthrough them. * Unread posts are significantly called out (green headers, experimental - this is fairly obnoxious but you are warned) * Topic titles are now hot * Rudimentary search functionality - Loading throbber - case insensitive - DOES NOT tokenize - searches titles, authornames, tags, postcontent * Clicking the gear icon now brings up a menu * Clicking the subscribe/unsubscribe stars now do things * Clicking the tag icon now opens a small dialog (that doesn't work yet); * Reply form auto-focuses to the textarea now.
Good iteration. :)
FWIW, on some of the smaller design issues like the chevron, I think you're using the right interaction, it just needs a little visual polish to make it easier to use. Same goes for the green color on unread/read state: that saturated color is jarring, but that is overall a good direction for indicating state. This is the nature of prototypes.
I have to say, especially in full chaos mode or the Jimmy Wales board I find the indenting to be quite hard to scan and read. One solution is to consider reducing to one indent level for all replies. The other direction we could go in is removing some of the heavier UI elements, and doing a progressive display of reply buttons and other actions on a post as you focus on it. I find multi-level indenting for threads is only really easy to scan when you have* a lot* of whitespace around blocks, ala Hacker News or our current style of indenting in MediaWiki, so reducing some of many elements on the page would help me scan more. The difficulty scanning might also in part be due to the fixed width of the prototype.
I still am confused about the feed and board model though, to be honest. Aren't notifications supposed to be an easy way to solve for the "tracking conversations" issue? The board is obvious in that it looks and behaves generally like all discussion systems in a broad sense, but when I look at the feed it's not really clear to me what it's comprised of (it looks at first glance just like a board) or why I need to go there, rather than just look for a notification about a reply to me. It's also obviously duplicating my watchlist in a big way.
On May 1, 2013, at 3:45 PM, Steven Walling swalling@wikimedia.org wrote:
I have to say, especially in full chaos mode or the Jimmy Wales board I find the indenting to be quite hard to scan and read. One solution is to consider reducing to one indent level for all replies. The other direction we could go in is removing some of the heavier UI elements, and doing a progressive display of reply buttons and other actions on a post as you focus on it. I find multi-level indenting for threads is only really easy to scan when you have a lot of whitespace around blocks, ala Hacker News or our current style of indenting in MediaWiki, so reducing some of many elements on the page would help me scan more. The difficulty scanning might also in part be due to the fixed width of the prototype.
In earlier versions, you could control the visual indent level from the left side. It broke when I switch to a different nesting system; I can try to bring that back.
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Le 2013-05-01 23:50, Brandon Harris a écrit :
I'm responding to everybody in this single mail, but first:
There is a new version at http://elohim.gaijin.com/flow/This is what's changed:
* Posts are automatically marked read as you scroll through them.
If you press the "page down" key, all posts are marked read (red?), I'm not sure that's what you want. I'm aware of at list one website[1] that maintain two "post attribute" for each post, and let user navigate previous/next element in this list through a dedicated navbox. The first list is a chronological one, so one may click next to follow posts has they were submited in time. The second one is a list of unred item, where clicking next will lead you to the next element in the page that you didn't read yet. This list is defined on a "since last download" base, which mean that if you download the page for the first time, all posts are marqued unread, but on your next download of the same page, only news posts will be marked unread.
[1] http://linuxfr.org (you need to be logged to access the "unred elements" list
* Unread posts are significantly called out (green headers,experimental - this is fairly obnoxious but you are warned) * Topic titles are now hot * Rudimentary search functionality - Loading throbber - case insensitive - DOES NOT tokenize - searches titles, authornames, tags, postcontent * Clicking the gear icon now brings up a menu * Clicking the subscribe/unsubscribe stars now do things * Clicking the tag icon now opens a small dialog (that doesn't work yet); * Reply form auto-focuses to the textarea now.
On Apr 30, 2013, at 4:05 PM, Trevor Parscal tparscal@wikimedia.org wrote:
First off, it's really awesome to have mockups and prototypes being done in HTML/CSS/JavaScript. This prototype is really cool and fun to play with. I know there are bugs and whatnot, but you've done a great job putting this together and I look forward to seeing more prototyping like this in the future.
A couple of things jumped out at me while I used it, hopefully some of this stuff is useful and new feedback. • The affordance for expand and collapse (a chevron symbol pointing right or down) didn't look like a control to me. I think that using symbols as buttons without outlining them is a great way to make the design lightweight, but if you make the symbol too big it looks more like a decoration and less like a control.
I agree; I went with chevrons because they are used in mobile for section expansion and I thought that having a similar theme would be useful. The first ones I used were . . . "fatter". . . but they felt clunky and blocky so we've got this.
Right now, I've made the entire title "hot" as well so as to increase the affordance size. They should also probably have a hover state to indicate that something is going to happen.
I'm absolutely open for better ideas.
• I think it's a good idea to be conservative about how many buttons to show, and I'm doubtful that an icon will convey "expand" or "collapse" very well, but the combined expand/collapse all button gets users into limbo states and can be a little confusing. Since items can be manually expand and collapsed, users can end up in a state where everything is expanded yet the button says "expand all". GMail uses an intermediate state for their select all button to show that you are in a partial selection state. Other interfaces often have both buttons always available. My impression is actually that this is a symptom of a larger problem (see next point).
The "Collapse all" button is actually there for ease-of-use in the prototype. I'm not really thinking it should make it into the final product because, as you said, the concept of "all" doesn't make a lot of sense in the context of a lazy-loaded, infinitely scrolling discussion system.
On Apr 30, 2013, at 4:56 PM, Brion Vibber bvibber@wikimedia.org wrote:
A few more notes:
- the collapse/expand is only available at the top level, which can
make it hard to really navigate through deeply nested long conversations -- especially if you were only interested in new content
So, this is what LiquidThreads does, and maybe we should revisit it. I worry, though, that having *too* many controls will be difficult to handle.
One possible solution to this (which I will prototype up) is to:
a) Automatically collapse read "branches" b) Only provide a control to *expand* those posts (and it wouldexpand all posts in the branch (so you don't have to do the horrible Quora style "click to open each comment)
- the appears-on-hover "(board * contributions)" links are hard to
discover and use on a touchscreen (for instance an iPad or other tablet that gets the desktop interface by default)
Jah. Erik asked that I provide minimal information and only do selective reveal, which isn't mobile-first but we're trying to illustrate concepts here rather than final functionality.
- I really want the entire thread title to be clickable as
expand/collapse, not just the little arrow. Much easier on touch, but I also tried to click on the title portion with my mouse on my laptop. :)
Done.
- The input box should probably expand to fit longer input
paragraphs, if possible (at least up to some reasonable size). Right now it's hard to edit a long response.
I'm doing some experiments with auto-sizing textareas but I'm not happy with anything I've gotten so far.
- Paging or infinite scroll need to be planned for for really long
talk pages.
Infinite scroll is the Plan™.
I agree that the "find new items" case isn't really handled well at this stage; there seems to be no "read/unread" distinction and scrolling through an entire thread to look for new things is very labor-intensive, especially on touch.
See above comment about collapsing.
Right now, I'm using a very obnoxious green header for each unread post. I do not expect this to last, but you DEFINITELY know if it's read or not.
On Apr 30, 2013, at 5:06 PM, Erik Moeller erik@wikimedia.org wrote:
My understanding from talking to Brandon earlier is that unread parts of the thread have a green vertical border right now, like the comments in the first example thread in http://elohim.gaijin.com/flow/ , and the idea is to make that fade out as you scroll over them (not yet implemented).
This is now implemented, but I'm not sure of the "action" yet. I'm using a library called "waypoints" and it works but there are lots of variables we can tweak.
On Apr 30, 2013, at 10:02 PM, Maryana Pinchuk mpinchuk@wikimedia.org wrote:
On a more general note, I'm still not sure I grok the board/feed distinction – I was thinking that new stuff would appear in your feed, and all stuff you follow would appear in your board, but that doesn't look to be the case.
More like the opposite:
Feed: Stuff you follow Board: Stuff about you and your activityThis is also a big problem I have with the concept behind LiquidThreads – if I'm already following pages on my watchlist, which is kind of my de facto feed, I really don't want to visit a separate "new messages" page unless it actually shows me a roll-up of all new messages related to those pages (as opposed to basically the full threads of three-year-old discussions, with one or two new messages buried somewhere in the middle). I'm also not sure how the watchlist is going to interact with Flow, given that, in essence, it's serving many of the user needs that Flow is trying to solve for (albeit in a weird, suboptimal way) at the moment. Have you done any thinking about how to delineate these features more clearly?
Lastly, the feed/board distinction (if I'm understanding it correctly) seems much more useful for when all discussions (village pumps, articles, the glorious future when messaging goes cross-project...) are Flow-enabled, not just user talk. Then there's an obvious need for seeing the stuff I may be semi-passively following from various scattered discussions on one view, and having a separate view for really important stuff directed specifically at me. Having two different views for just user-to-user messaging, though, feels too heavy to me. Why not just one for now?
Actually, the feed solves for two very distinct use cases that are not addressed by the board:
1) Conversations occurring across multiple talk pages 2) Tracking conversations that you are involved in on otherpeople's talk pages
While I had originally spent a lot of thought on the "single board, two viewpoints" solution, in the end having a board/feed model made more sense to me because:
1) User talk pages already *kind of* match the "board" model (andmapping contributions into it isn't that much of a leap) 2) Most people are used to the concept of "my stuff" versus "the stuff I'm following", even if there are many ways this is done: Facebook has a "Profile" and a "Feed" Twitter has a "Profile" and a "Stream" LiveJournal has a "Journal" and a "Friends Page" etc. 3) We can probably roll out easier. We give *all* users a Feed, but then users can selectively "upgrade" their talk pages to "Boards". This gives users flexibility as to when they move into the Bright Future.
On May 1, 2013, at 12:53 AM, Jon Robson jrobson@wikimedia.org wrote:
When clicking save the text under is very wordy. I wonder if this could be collapsed somehow
This is a requirement from legal. There's no real way around it.
pps. the be nice placeholder is a lovely touch. A subtle reminder of the community we want/ need to foster.
Kind-of-not-quite "accidental". :)
On May 1, 2013, at 4:01 AM, Mathieu Stumpf psychoslave@culture-libre.org wrote:
When you click reply, you should directly have the textfield focused. Also within the textfield pressing tab should let you switch to the save button, then the cancel button, with a highlight which let user know which element is focused.
I've got the textarea focusing but there's some goofiness I ran into with handling tabindex on the other elements. I'll see what I can do about it but at the end of the day this is only about half as powerful as it will be when it is truly backed by a server-side system.
Always reducing the box with a bigger left margin is not great for very deap threads. I have no perfect solution to give instead those said. Maybe having a "box-min-size" test that will change the comportement when reached, for example you may go back to a bigger box but with a right margin and using right box borders to let users follow the flow.
Right now, I'm not applying any logic to how deep the branches can go. I've got an exhaustive analysis of branch depths located at mw:Flow Portal someplace; I think the final layout is going to be "branch in for 4 levels, and then go 'flat'" but I wanted to get it out in an easy state first.
Applying this kind of functionality WILL have an effect on the conversation style and norms but I don't think that's a bad thing.
I think tags/subscribe/other icons should be more spaced.
This should be easy to do.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Hello,
When you click reply, you should directly have the textfield focused. Also within the textfield pressing tab should let you switch to the save button, then the cancel button, with a highlight which let user know which element is focused.
Always reducing the box with a bigger left margin is not great for very deap threads. I have no perfect solution to give instead those said. Maybe having a "box-min-size" test that will change the comportement when reached, for example you may go back to a bigger box but with a right margin and using right box borders to let users follow the flow.
I think tags/subscribe/other icons should be more spaced.
Otherwise to my mind that's looks realy great.
Le mardi 30 avril 2013 à 14:16 -0700, Brandon Harris a écrit :
I have thrown together an interactive prototype of Flow. It's fairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/
Nothing is saved to disk. You can reply to topics or even add new ones but on refresh everything reverts to state. Right now, the "you" you are logged into is "Jorm" but I'll be adding functionality to handle that.
In the sidebar are a couple links to various "board examples":
* Fully Chaos (everything is generated randomly.) * Jimmy Wales * Maggie Dennis (Moonriddengirl) * Me * A single topic (this is what you get to if you get an echo notification)Speaking of, if you click the echo badge, and then click on the unread notification, you'll get the experience of the user getting a reply and going to the single conversation view.
You can also click the "Feed" link and you'll be brought to your feed. The "feed" view is different from the "Board" view. The feed is private - it's all the conversations that you my be interested in or are subscribed to (have a solid star). You also see activity from the boards of *people* you're subscribed to as well, but it floats away fairly quickly if you don't subscribe to it.
Known bugs:
* The "New Topic" dialog doesn't close when you click the "X" button. No idea why; it worked the other day and now it doesn't. * Some of the conversations are threaded weird. This is an artifact of the JSON. * The tab highlights are a bit goofy.Upcoming:
* The search functionality will work * You'll be able to add and edit tags * Stuff like archive/split/whatever * Edit your own post, etc.Please share your thoughts.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
What browser is this written for? I'm not saying it needs to be cross-compatible, but knowing which it's most likely to work as intended in might help here.
Anyway, some thoughts on top of what others have already mentioned -
1. Using a popup for new messages is probably not the best way to go - it constrains what users can do, preventing the use of any links on the page or scrolling down and looking at other comments/replies already there, or even opening the original page in a new tab. If they change their minds, there are only two ways out, the cancel or the X, before they can do anything else, instead of just allowing the user to directly go to their watchlist or whatever if they realise they'd rather be there. Something more like how wordpress does it by default would probably be better, just having a regular comment input in a linkable div - it can expand at top or bottom and the rest of the page is still the rest of the page. 2. Why is the reply button on the left? I know that's the current setup, but such is a forward action, and in ltr languages forward seems more to the right. 3. Everything is so very large. Less bulky containers would be good, not just for lack of a ToC, but also simply to make it easier to follow things in general. Everything collapsed only gets under ten threads visible, and expanded about four comments fit on this screen, even when each comment is only a couple lines long, because of how large the containers are - 167px tall just to say 'Okay.' to someone shouldn't be necessary. 4. Actually, why not add a ToC? Sure, it's a dynamic page/feed/thing, but a straight list of everything on the page at the time could be useful for desktop users. 5. Why is one's own new comment marked as unread? Or is that what the green means? 6. Do the target communities want the user info so prominently displayed? I got complaints about that when I was working on this before, at least. so it may something worth looking into especially since if not it is kind of cluttering (and there are also more social concerns). 7. It'd be nice if we could get away from the star thing as a design pattern. It's just confusing - watched pages, featured articles, subscribed threads... it should only be one of those, not all three. 8. Having the green highlighting of new stuff go away entirely after coming to it could be problematic - folks don't necessarily read as fast as they scroll or whatever, and when entering a whole mass of things it helps to have an indication what was new even when reading it. Having it go away immediately would make it likely for folks to miss things entirely as a result, especially since there doesn't seem to be any middle ground or quick way to jump from new thing to new thing. 9. Having the entire header as a collapse/expand handle is good, though I assume it won't bounce in reality because for some reason it started bouncing between expanded and collapsed when I clicked on one. 10. Something about reddit. 11. Where would the tools/options for specific comments go? Folks will need to be able to edit them, delete them, etc. 12. Two lines of textarea in which to reply isn't much. Even if one is only leaving a single line comment, it's still more comfortable to have more room in which to edit, and many comments/replies can be much longer. Even the editwarning is more than two lines. 13. Reply button should probably go away when replying, or turn into a header or something. Otherwise folks might be tempted to click it again to see if they can reply multiple times, but having it cancel the reply is not likely to be expected behaviour. 14. That little triangle thing on the reply box seems out of place. I'm not a fan of those triangles in general, but really they seem to be for flyouts and such that need some affordance to indicate what they're attached to, but a reply doesn't feel like a flyout, even if it is expanding. And it should be pretty obvious what it's attached to since it's inserting right below the target. 15. What's the number in the oval for and can it be used for navigation? 16. VisualEditor doesn't work in all browsers. I assume this is laid out with that in mind? 17. The visual difference the headers provide should be more significant. Somehow. 18. The 'Be nice' thing actually seems kind of scolding - implying that folks aren't normally nice and need to be constantly reminded to behave. While this is indeed the case on many projects, it seems somewhat contrary to the idea of assuming good faith.
Hope that helps, or is at least coherent. This is an interesting start.
On 30/04/13 22:16, Brandon Harris wrote:
I have thrown together an interactive prototype of Flow. It's fairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/
Nothing is saved to disk. You can reply to topics or even add new ones but on refresh everything reverts to state. Right now, the "you" you are logged into is "Jorm" but I'll be adding functionality to handle that.
In the sidebar are a couple links to various "board examples":
* Fully Chaos (everything is generated randomly.) * Jimmy Wales * Maggie Dennis (Moonriddengirl) * Me * A single topic (this is what you get to if you get an echo notification)Speaking of, if you click the echo badge, and then click on the unread notification, you'll get the experience of the user getting a reply and going to the single conversation view.
You can also click the "Feed" link and you'll be brought to your feed. The "feed" view is different from the "Board" view. The feed is private - it's all the conversations that you my be interested in or are subscribed to (have a solid star). You also see activity from the boards of *people* you're subscribed to as well, but it floats away fairly quickly if you don't subscribe to it.
Known bugs:
* The "New Topic" dialog doesn't close when you click the "X" button. No idea why; it worked the other day and now it doesn't. * Some of the conversations are threaded weird. This is an artifact of the JSON. * The tab highlights are a bit goofy.Upcoming:
* The search functionality will work * You'll be able to add and edit tags * Stuff like archive/split/whatever * Edit your own post, etc.Please share your thoughts.
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 04/30/2013 05:16 PM, Brandon Harris wrote:
I have thrown together an interactive prototype of Flow. It's fairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/
Thanks for doing this - and thanks to everyone for thoughtful praise, criticism, and questions. Honestly it might be worth choosing a few posts from this thread to link to as examples from https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/How_to_give_desig... and to use for the feedback template.
Honestly, I just want people to leave their feedback as raw and simple as they can on the wiki page that is linked from the sidebar.
Adding overhead process to giving feedback about design results in less feedback. I don't want people to have to read an instruction booklet before they feel like they can tell me if they like or hate something.
On May 5, 2013, at 10:32 AM, Sumana Harihareswara sumanah@wikimedia.org wrote:
On 04/30/2013 05:16 PM, Brandon Harris wrote:
I have thrown together an interactive prototype of Flow. It's fairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/
Thanks for doing this - and thanks to everyone for thoughtful praise, criticism, and questions. Honestly it might be worth choosing a few posts from this thread to link to as examples from https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/How_to_give_desig... and to use for the feedback template.
-- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Hi,
I totally agree with your on "nobody wants to read instructions" but I think that leaving the context is not a very good idea if you really want to have feedback. If I click on "Leave Feedback", I get to an empty wiki page, get confused and never try to give feedback again.
At the moment I'm writing a gadget based on the mediawiki extension I developed for my bachelor-thesis. It allows users to send feedback in the form of a screenshot with annotations.
Here you can try the actual version of this feedback mechanism (the green feedback-button on the right side of the page; when you click on send a screenshot of the page is rendered and appended to the site)
http://lb.bombenlabor.de/ba/test/wikidata.html
Lukas
Am So 05.05.2013 19:45, schrieb Brandon Harris:
Honestly, I just want people to leave their feedback as raw and simple as they can on the wiki page that is linked from the sidebar.
Adding overhead process to giving feedback about design results in less feedback. I don't want people to have to read an instruction booklet before they feel like they can tell me if they like or hate something.
On May 5, 2013, at 10:32 AM, Sumana Harihareswara sumanah@wikimedia.org wrote:
On 04/30/2013 05:16 PM, Brandon Harris wrote:
I have thrown together an interactive prototype of Flow. It's fairly functional and I intend to make it even more so.
You can play with it here: http://elohim.gaijin.com/flow/
Thanks for doing this - and thanks to everyone for thoughtful praise, criticism, and questions. Honestly it might be worth choosing a few posts from this thread to link to as examples from https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/How_to_give_desig... and to use for the feedback template.
-- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
(Chopping many people from the cc list)
(Two topics in this)
First, based on my comment here:
On May 5, 2013, at 10:45 AM, Brandon Harris bharris@wikimedia.org wrote:
Adding overhead process to giving feedback about design results in less feedback. I don't want people to have to read an instruction booklet before they feel like they can tell me if they like or hate something.
I've gone ahead and WP:BOLDly reworked
https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/How_to_give_desig...
into something that is a little more end-user friendly. We want more feedback, not less.
On May 5, 2013, at 12:24 PM, Lukas Benedix benedix@zedat.fu-berlin.de wrote:
Hi,
I totally agree with your on "nobody wants to read instructions" but I think that leaving the context is not a very good idea if you really want to have feedback. If I click on "Leave Feedback", I get to an empty wiki page, get confused and never try to give feedback again.
At the moment I'm writing a gadget based on the mediawiki extension I developed for my bachelor-thesis. It allows users to send feedback in the form of a screenshot with annotations.
Here you can try the actual version of this feedback mechanism (the green feedback-button on the right side of the page; when you click on send a screenshot of the page is rendered and appended to the site)
This is the type of gadget we'd like to have but the problem is that we need it to be able to run in situations where:
1) There isn't a wiki 2) We don't have a backing store on the server that we're running it on
(Yeah, I know. Not very easy.)
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
On 6 May 2013 14:21, Brandon Harris bharris@wikimedia.org wrote:
On May 5, 2013, at 10:45 AM, Brandon Harris bharris@wikimedia.org wrote:
Adding overhead process to giving feedback about design results inless feedback. I don't want people to have to read an instruction booklet before they feel like they can tell me if they like or hate something.
I've gone ahead and WP:BOLDly reworkedhttps://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/How_to_give_desig...
into something that is a little more end-user friendly. We wantmore feedback, not less.
Love it. Thank you, Brandon!
J.
1. is not a problem: it's only css + js without any dependencies on mediawiki
2. not yet implemented, but I think the feedback could be sent to a mediawiki (append the text to a feedback-page and upload the screenshot via the upload api)
Lukas
Am Mo 06.05.2013 23:21, schrieb Brandon Harris:
This is the type of gadget we'd like to have but the problem is that we need it to be able to run in situations where:
1) There isn't a wiki 2) We don't have a backing store on the server that we're running it on(Yeah, I know. Not very easy.)
I added a "be focused" section.
Especially on early prototypes you also want the conversation to focus on a specific aspect. You may have a clickable prototype where most links don't work and graphical elements are not polished because you want to just focus on the overall navigation.
So if the design is presented with specific design goals or a specific scenario, it is desirable to (a) focus the feedback on those, or (b) raise an issue of the scenario not being representative.
Pau
On Tue, May 7, 2013 at 1:44 AM, Lukas Benedix benedix@zedat.fu-berlin.dewrote:
- is not a problem: it's only css + js without any dependencies on
mediawiki
- not yet implemented, but I think the feedback could be sent to a
mediawiki (append the text to a feedback-page and upload the screenshot via the upload api)
Lukas
Am Mo 06.05.2013 23:21, schrieb Brandon Harris:
This is the type of gadget we'd like to have but the problem isthat we need it to be able to run in situations where:
1) There isn't a wiki 2) We don't have a backing store on the serverthat we're running it on
(Yeah, I know. Not very easy.)______________________________**_________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/designhttps://lists.wikimedia.org/mailman/listinfo/design
I'm having problems telling users where they're supposed to leave feedback. The old prototype links a wiki page whose talk says to leave feedback there, but it's empty and didn't have LQT. I suggest to include a link to a feedback page or whatever in the sidebar.
Nemo
Right. The sidebar link is still there - or it least it is for me.
I actually do NOT want to have LQT on that page; enwiki people are very distrustrful of LQT.
On May 9, 2013, at 4:49 AM, "Federico Leva (Nemo)" nemowiki@gmail.com wrote:
I'm having problems telling users where they're supposed to leave feedback. The old prototype links a wiki page whose talk says to leave feedback there, but it's empty and didn't have LQT. I suggest to include a link to a feedback page or whatever in the sidebar.
Nemo
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Brandon Harris, 09/05/2013 18:23:
Right. The sidebar link is still there - or it least it is for me.
Sorry, can't find it.
Nemo
P.s. on tangential topic:
I actually do NOT want to have LQT on that page; enwiki people are
very distrustrful of LQT.
I'm more than distrustful of LQT, I positively loathe it; however, this means little. It doesn't matter to me, I was just applying what is AFAIL a recommendation for talk pages on mw.o.
On May 9, 2013, at 10:37 AM, "Federico Leva (Nemo)" nemowiki@gmail.com wrote:
Brandon Harris, 09/05/2013 18:23:
Right. The sidebar link is still there - or it least it is for me.
Sorry, can't find it.
First line, under the toolbox, "Leave feedback"
--- Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate