Unlabeled search box

[reziac]

Title:
Unlabeled search box

Area:
Confusing the user, especially the novice

Summary:
The search box in the upper right needs its own label, NOT just the mouseover label.

Description:
The search box in the upper right needs its own label, NOT just the mouseover label. If someone doesn't realise what it is, the dropdown appears to *go* to "Interest" (etc.) with an expectation of some general page appearing, compounded by the button saying "GO" (normally that's an indication that a *dropdown box* will work without javascript) rather than "Search". It got *me* that way, having not run my mouse far enough over and not being a fan of intrasite search so I just didn't think of it (if anything, I'd vaguely wondered what the blank box to the left was for, but didn't investigate as I was distracted by the dropdown).

Anyway, I'm sure the words "search Dreamwidth" wouldn't be too much to squeeze in, perhaps immediately below the box. ;)

You really do have to specify WHAT such a form searches (not just "Search"), because user expectation is that ANY search box searches the whole dang world a la Google. There was a good article recently on this, somewhere on Jacob Nielsen's mondo excellent Usability site, http://www.useit.com/alertbox/

As to my previous poor rejected suggestions, which proved redundant to DW's Master Plan, great minds think in similar... what's that noise?? <g>

Poll #9493 Unlabeled search box

Open to: Registered Users, detailed results viewable to: All, participants: 50

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
22 (44.0%)

Should be implemented with changes. (please comment)
4 (8.0%)

Shouldn't be implemented.
5 (10.0%)

(I have no opinion)
19 (38.0%)

(Other: please comment)
0 (0.0%)

OpenGraph implementation

[skakri]

Title:
OpenGraph implementation

Area:
frontend, accessibility, cross-site data sharing

Summary:
It would be nice if sites, that use OpenGraph metadata, could use our provided data, instead of crawling the page in question and collecting arbitrary data (article image, article title, author, etc.)

Description:
Sites that support OpenGraph Protocol (http://ogp.me/), like Facebook and Google+ would benefit from already provided data; that would help those sites 1) categorize that data (entry title, tags), 2) provide correct information, when posting to FB or G+ (title, image), instead of full page title (username | post, for example).

Example - http://skakri.grab.lv/2360053.html (check source; done: profile username, entry image, entry title, publishing date and used tags). Could be implemented also in profile pages - user.domain.tld/profile

Poll #9490 OpenGraph implementation

Open to: Registered Users, detailed results viewable to: All, participants: 40

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
5 (12.5%)

Should be implemented with changes. (please comment)
1 (2.5%)

Shouldn't be implemented.
3 (7.5%)

(I have no opinion)
31 (77.5%)

(Other: please comment)
0 (0.0%)

Fluid width content on entry pages

[little_terror]

Title:
Fluid width content on entry pages

Area:
styles, entries, usability

Summary:
Fluid width content on entry pages to improve usability and readability.

Description:
At the moment, DW only seems to provide fixed content on default/unstyled entry pages. Because of the fixed content parameters, overwhelming whitespace can be an issue for larger monitors and computers running higher resolutions. Moreover, long comment threads end up "shrinking" very quickly, necessitating users to click more links (such as thread or expand) in order to view content.

Fluid width for entry pages would decrease the amount of uncomfortable whitespace users running higher resolutions encounter. Fluid width would also prevent long comment threads from shrinking too quickly and decrease the amount of clicking users are required to do at present.

Implementation of fluid width should not be difficult, as the style sheet that currently powers the default entry style only needs to have fluid width coded into style containers.

In conclusion, fluid width would improve usability and readability across platform and resolution. I hope the DW development team considers this suggestion!

Poll #9492 Fluid width content on entry pages

Open to: Registered Users, detailed results viewable to: All, participants: 51

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
10 (19.6%)

Should be implemented with changes. (please comment)
5 (9.8%)

Shouldn't be implemented.
20 (39.2%)

(I have no opinion)
13 (25.5%)

(Other: please comment)
3 (5.9%)

Profile: Circle: link 'Edit' link to corresponding section at Manage Circle

[ninetydegrees]

Title:
Profile: Circle: link 'Edit' link to corresponding section at Manage Circle

Area:
profile

Summary:
When you're viewing your own profile, there's an 'Edit' link next to People, Communities and Feeds which goes to the Manage Circle page. People, Communities and Feeds are in three different sections on this page. It would be neat if the profile links linked you to the corresponding section instead of just the page.

Description:
.

Poll #9491 Profile: Circle: link 'Edit' link to corresponding section at Manage Circle

Open to: Registered Users, detailed results viewable to: All, participants: 55

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
45 (81.8%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
1 (1.8%)

(I have no opinion)
9 (16.4%)

(Other: please comment)
0 (0.0%)