Australis reload button

Daniel Cardin thadancardin at gmail.com
Mon Nov 25 00:51:59 UTC 2013


I suggested almost exactly this proposal when the discussion over the
changes happened a couple of months ago. The response was that the first
way was too complex and having two different buttons that did the same
thing was bad. I never got a good response as to why the 2nd wasnt a good
solution. Its simple and not as magic-y.

If you wanted as little magic as possible, I also suggested having an (for
example, for the reload button, ) overlay showing a semitransparent version
of the combined button (e.g. navigation having a semitransparent reload
button when there's no reload button placed on the toolbar, to show that
one will be placed) when in the customization mode. But that's just added
candy that's not really necessary.


On Sun, Nov 24, 2013 at 6:15 PM, Eric Shepherd <eshepherd at mozilla.com>wrote:

> I for one like this proposal.
>
> Eric Shepherd
> Sent from my iPhone
>
> On Nov 24, 2013, at 6:09 PM, Florian Bender <florian.bender at quantumedia.de>
> wrote:
>
>  Hi Mike,
>
> there are so many people wanting a separate reload (and navigation)
> button, and while I completely agree with the course of the „giant
> navigation widget“, I’d like to propose a change:
>
> 1. Add separate buttons for (combined) reload/stop and maybe
> backwards/forwards (latter one always visible) to the default set of
> available buttons, but „hide“ them initially in the customization pool (so
> people who want those buttons to be somewhere else, need to drag them to
> the toolbar first).
> 2. (optional) When someone drags them into the toolbar, hide their
> respective entities from the navigation widget. This re-introduces some
> magic, but way less than was necessary for the previous auto-merge behavior
> (it’s basically a if-available script + set selector + `display:none`).
>
> I think the maintenance cost of this proposal is minimal, and would make
> many people happy without compromising the Australis goals. Also, although
> this can be easily done through an add-on, it should be included by default
> because this helps reducing omg-change impact and show more customization
> friendliness (with very little cost).
>
> I could also see this for the bookmarks widget / bookmark star in the
> location bar: Show the bookmark star in the location bar when the bookmarks
> widget is removed from the toolbar (and optionally add a separate bookmark
> menu widget which is only the „right“ part of the current bookmarks widget)
> – though this is probably a bit more complicated than the cases above.
>
>
> Best regards,
>
> Florian Bender
>
>
>
> · quantumedia | Kalchthaler, Müller & Partner GbR
> Neuhäuserstr. 130 · 79199 Freiburg/Kirchzarten · Tel. 0761 458 99 28-0
> USt-IdNr: DE280390014 · Geschäftsführer: Gregor Kalchthaler, Philipp
> Müller
>
> Am 20.11.2013 um 14:55 schrieb Mike de Boer <mdeboer at mozilla.com>:
>
> On Nov 20, 2013, at 1:39 PM, Eric Shepherd <eshepherd at mozilla.com> wrote:
>
> I did just think of one thing I didn't mention yesterday; I don't like the
> tiny little reload button in the URL bar that, as far as I can tell, cannot
> be moved back out into the toolbar where I'm used to it being. That's a
> very small click target and a very big change to try to adapt to using
> Cmd-R all the time instead of clicking the button. I'm sure I can adapt to
> that, but it's a really disappointing loss of customization.
>
>
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20131124/f214f3da/attachment.html>


More information about the firefox-dev mailing list