Closed Bug 278221 Opened 20 years ago Closed 14 years ago

Redesign cookie prefs and split Managed Stored Cookies into Cookie Site Management/View Cookies

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: iannbugzilla, Unassigned)

References

Details

Attachments

(3 files)

Once bug 270170 has landed, I'm looking at splitting the site management part of
cookies from the view/management of cookies themselves and redesign the cookie
pref screen along similar lines to the cookie prefs screen on firefox.
At the moment the cookie prefs screen runs off the bottom of the preferences
page and various options that probably be disabled at certain times are not.
Blocks: 277097
Status: NEW → ASSIGNED
"for the originating website only" and "based on privacy settings" will not
both be able to be checked at the same time the logic will uncheck the opposite
to the one being checked. Both can be unchecked though.
"based on privacy settings" and "View Privacy Settings" will only be visible if
P3P is installed.
Everything apart from "Cookie Sites" and "Manage Stored Cookies" become
disabled when "Allow websites to set Cookies" is unchecked.
No longer blocks: 277097
Depends on: 277097
could you attach a pic of the current cookie pref page for easier reference
What it looks like at the moment
hrm.

a) the proposed stuff has more holes in it than the current design, but I'm not
going to review at length here.  Suffice to say: needs-work+
b) there's disabling issues, there's bugs on those, but seamonkey hacking is
pretty far down my list.
c) spilling by one line because one word wraps isn't much of a reason to rewrite
the prefpanel.
d) this doesn't look much like "sustained engineering path, stable UI/features"
e) why are we bringing back "the blurb" at the top?  We agreed last time around
to kill it.  If a user wants to know what it is, they'll click Help.

d) probably concerns me most.  The previous UI was pretty bad, so we cleaned it
up, but redesigning again in another radical departure.

I'll leave this open pending you convincing me that we need to rework this,
again, for a "stable" project.  If you convince me its worth it and appropriate,
then we have some significant changes to make.
Just saw the screenshot of the new preference dialog, and I am not convinced.

I find information harder to find, and also UI inconsistency. Why should the
first line have the [cookie sites] button on the right of the text mentionning
cookie sites, while the [privacy settings] button is not placed at the same line
where "privacy settings" is referenced?

One thing that I also found disturbing was the fake alignment below the "based
on privacy settings" and "Cookie lifetime policy" lines. It looks like the sheft
should be more shifted to render nicely. But that's perhaps because of the draft
issue.

Finally I liked the 3 blocks in the former UI. They structured my reading and
helped me focus on less information on the UI. Now everything is in one block
BTW why do you need it? The title of the page is Cookies and the block is
cookies as well. Looks like lost space to me.

One question: why one does open this dialog? I open it most of the time to
manage my stored cookies. It may not be representative of the main usage, there
are 2 distincts use of the cookies dialog.
- set up the cookies preferences
- manage the stored information (sites, cookies)

Those who accept cookies probably almost never reopen it, isn't it?
(In reply to comment #1)
> "for the originating website only" and "based on privacy settings" will not
> both be able to be checked at the same time the logic will uncheck the opposite
> to the one being checked. Both can be unchecked though.

Don't Do That. Checkboxes aren't radiobuttons. I don't expect a checkbox to
switch off another checkbox.

(And why isn't this in the cookie component?)
screenshot of the Cookies pref. Monitor resolution 1280 x 1024, Win XP styles
applied.
Monitor resolution is affecting the display of the pref panes in Win XP. If one
is using Windows XP styles, the Manage Cookies button is not visible at all. I
have to switch to Windows Classic mode to use this function. This bug is
affecting several of the prefs panes' display, but it's a real pain for cookies,
as this is the most common reason for going in to the prefs. I vote for
providing splitting this pref and putting manage cookies on it's own pane. 
The missing manager button would be a different bug. Not this one.
Flags: blocking-seamonkey1.0a?
Not going to hold up SM 1.0a for this.
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a-
Ian,
Are you still working on this ?
Yes, way down the list though.
As far as I am aware no longer an issue with pref panel size and data manager should cover the other side of this bug - WONTFIX
Assignee: iann_bugzilla → nobody
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
QA Contact: pawyskoczka → ui-design
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.