Closed Bug 548764 Opened 14 years ago Closed 10 years ago

The non-billboard pages need UI redesign

Categories

(Toolkit :: Application Update, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: robert.strong.bugs, Unassigned)

References

Details

(Keywords: uiwanted)

Attachments

(2 files, 1 obsolete file)

See attached screenshots
Attachment #429074 - Attachment description: Windows screenshots - two pages on the left → Windows screenshots - two pages on the right
Attachment #429075 - Attachment description: Mac screenshots → Mac screenshots - two pages on the right
Since the width of the UI will be much larger than originally due to the design provided in bug 480178 all of the wizard pages will have tons of empty space so morphing this bug to handle all of the pages besides the billboard page.

The only thing I can think of that would be reasonable is to do something similar as preferences does in that it could animate / fade in to resize the UI. The difference would be that the width would also need to be changed which would require not only changing the width but also changing the position so the UI would stay centered horizontally to its original position. I wouldn't be surprised if doing this would end up being a tad jerky due to the repositioning.

faaborg / beltzner, I'd appreciate your thoughts on this
Summary: The non-billboard updates found page and finished background download page need some love → The non-billboard pages need UI redesign
Attached image Win7 screenshots
Attachment #429074 - Attachment is obsolete: true
Keywords: uiwanted
Happy to take a look at this, but can you tell me a bit more about what the constraints are? Do these windows *have* to be the same size as the major update dialog? Are there any other limitations I have to keep in mind?

The obvious easy improvement would be to resize them according to the content we need to show, as the only dialog that needs all that space is the major update panel that has the feature overview.
(In reply to comment #6)
> Happy to take a look at this, but can you tell me a bit more about what the
> constraints are?
sure

> Do these windows *have* to be the same size as the major
> update dialog?
No but changing size should keep in mind that button position will change and could at the very least be disconcerting when the button would typically be in the exact same place as the previous button. It would also be nice to at least keep every page besides the billboard page the same width and if possible the same heoght.

> Are there any other limitations I have to keep in mind?
Not particularly but I think it is important to note that there are pages prior to the billboard page so if the page size does change width that there are pages prior to the billboard page that I suspect in the design would not be as wide so it would go slim -> wide slim which I think would be rather funky. Also, if widths change I am quite sure our widget toolkit doesn't handle keeping the UI centered from the previous position which would quite likely make the change somewhat jerky on some systems.

> The obvious easy improvement would be to resize them according to the content
> we need to show, as the only dialog that needs all that space is the major
> update panel that has the feature overview.
Yep though I am concerned about not having a minimum width for pages other than the billboard if it is decided to make the width smaller for pages other than the billboard page and not having a minimum height considering that resizing to fit content would basically reduce the height way too much IMO considering the small amount of text on several of the pages. We could do something similar to the preference panel on Mac OS X as pointed out in comment #3 but I think it might be better to just have a consistent size that is smaller than the billboard page so buttons don't move around.
my apologies for jumping to higher level questions in such a specific bug, but for Firefox in what cases will we be displaying this dialog?  Alternative ways of informing the user include (from most ambient to most interrupting):

-silent
-home tab snippet
-firefox button style change
-firefox button panel notification
-modal dialog box
Besides a manual check for updates there are
* App version change where an add-on that is enabled will be disabled due to it being incompatible with the new version. This is a Firefox default preference and the user can disable this by unchecking "Warn me if this will disable any of my add-ons".
* User changing the preference to "Ask me what I want to do"
* The update snippet specifying showPrompt. In the past we always showed the UI for major updates... this puts the application in control of when the prompt will be displayed vs. downloading in the background if the conditions are met for the update to be downloaded in the background.

I haven't heard of any guidelines as to when Firefox will use showPrompt in the update snippet and since they aren't code driven I doubt the rules would be set in stone. beltzner would likely be able to provide more details about when Firefox will specify showPrompt.

Keep in mind that any notification would require showing additional info beyond that there is an update available such as "the following add-ons will be disabled" which is likely the typical case though there could be others and that list should be generated at the time of user acknowledgement since the list could easily change by the user installing / uninstalling / disabling add-ons since the initial notification.
We also always show the prompt with a link to download the new version for the case where the user is unable to apply an update due to lack of permissions... I might have missed other cases but nothing comes to mind
There is another bug to handle this.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.