I'm interested in the tracking bug for followup requests as well, and where to file feature requests.

I'd love to see a "date changed" column on that page, for example.

Future-wish bikeshedding aside, this is good work, thanks to you and your team.

- mhoye


------ Original Message ------
From: "Frederik Braun" <fbr...@mozilla.com>
To: "Tom Schuster" <t...@schuster.me>
Cc: "Axel Hecht" <l...@mozilla.com>; "dev-platform" <dev-platform@lists.mozilla.org>
Sent: 2019-01-25 8:55:46 AM
Subject: Re: New and improved "about:config" for Firefox Desktop

Agreed. If there's one special feature besides search I've been using most,
it was sorting by modified

Am Fr., 25. Jan. 2019, 12:16 hat Tom Schuster <t...@schuster.me> geschrieben:

I am always happy to see more xul going away.

Please implement a filter to only show modified preferences. Sorting
by modified is probably my most common operation after search on the
old page.

Thanks

On Fri, Jan 25, 2019 at 11:40 AM Axel Hecht <l...@mozilla.com> wrote:
>
> Is there a tracking bug for follow-ups?
>
> I'd have a few, adding pref w/out search (*), show add on screen for
> long searches, filter/order by modified, search in values, can't abort
edit.
>
> (*) I just realize that I didn't understand how "add" works. Maybe the
> bug is to make that discoverable?
>
> Axel
>
> Am 24.01.19 um 20:31 schrieb Paolo Amadini:
> > Last year a group of students, Luke, Matthias, and Vincent, designed
and
> > implemented a new version of "about:config" in order to improve the > > ergonomics and align the look and feel with other in-content Firefox > > pages. They did an amazing job, working with design input from Amy Lee
> > and with myself doing code reviews.
> >
> > I'm happy to announce that this work will be available to everyone in
> > Firefox 67, and can be already used in Nightly at this URL:
> >
> >      chrome://browser/content/aboutconfig/aboutconfig.html
> >
> > Most improvements are the natural result of using HTML instead of XUL:
> >
> >   * There are visible buttons for editing preferences
> >   * String values are displayed in full as multiline text
> >   * Find in page works for both names and values
> >   * Triple click selects one preference name or value quickly
> >   * Text selection works on multiple preferences
> >   * The context menu is the same as regular web pages
> >      - Copy to the clipboard
> >      - Open selected link
> >      - Search with your preferred engine
> >   * Search results don't include spurious value matches anymore
> >   * Closing and reopening the browser while the tab is pinned
> >       preserves the search term
> >
> > We've not just converted the old page, we've designed something new > > based on actual use cases, telemetry data, and opportunity cost. We > > preferred natural HTML page interactions, for example a double click
now
> > selects text instead of toggling the value. The way the page is
explored
> > with screen readers has also changed, and we've ensured that the new
way
> > is still clear and easy to use.
> >
> > We're still keeping the old "about:config" around at the following URL
> > for a while, to mitigate risk related to unforeseen circumstances:
> >
> >      chrome://global/content/config.xul
> >
> > Thunderbird will not be affected by this change initially, but at some > > point we'll remove the old code from mozilla-central since Thunderbird
> > will be the only remaining user.
> >
> >
> > *Performance*
> >
> > This page can be slower than the old one in some cases. On slower
> > machines the page may take a moment to display all preferences, if you > > so choose. We worked around this by waiting for the first input before
> > displaying results, as 93% of "about:config" page shows include a
search
> > anyway. Navigation, scrolling, and find in page are then fast.
> >
> > We've used performance profiling to optimize the page and avoid the > > slowest layout modes, but we've not compromised on using the latest > > best practices for Firefox Desktop like Fluent localization, which are
> > anyways in the process of being optimized on their own.
> >
> > We've explicitly chosen to avoid virtualizing the list, that is only > > rendering visible DOM nodes, because this would add complexity that is
> > not needed for an internal page. It would also nullify most of the
> > advantages in accessibility and usability that we gained at a low cost > > just because we're using a simple HTML table. Effort would be better > > spent on optimizing the web for the layout of tables of about 3,000
> > rows, which would benefit every web site instead of Firefox only.
> >
> >
> > *Tutorials and screenshots on the web*
> >
> > While with some features there is a concern that a change would make it
> > more difficult for users to follow instructions found in older
tutorials
> > on the web, this is much less of a concern in this case, given that the > > page caters to experienced users and the changes affect presentation
> > rather than actual functionality.
> >
> > In fact, existing information on the web can more easily become
obsolete
> > because the preferences go away or change their meaning, rather than
> > because of a change in how the values can be changed.
> >
> >
> > *Features that have not been rewritten*
> >
> > If the new page is missing a feature that the old one used to have, > > there is probably a good reason. Luke added telemetry probes to the > > current "about:config" so we know how people use it. It's basically
just
> > one mode of operation across all channels: search, then maybe edit or
> > add a preference.
> >
> > There are more details in the history section below, but this is to say > > that it is unlikely that we would accept a patch to add back a certain > > feature just because it used to be present before. All patches would
> > have to be motivated by an actual need and include exhaustive
> > regression tests.
> >
> > That said, we have ideas for supporting new use cases for browser
> > developers, like pinning a list of favorites or just showing recently > > modified preferences first, but we don't plan to start working on them
> > before the current version reaches Release.
> >
> >
> > *More details on history, motivation, and process*
> >
> > If you're reading this you probably already have a good idea of what > > we're talking about, but it's worth stating how we thought about the
> > project when we approached it.
> >
> > "about:config" allows the occasional modification of application data > > that developers have chosen to store using the internal Preferences
API.
> > This may be operational data, feature flags, or settings that cannot be
> > modified anywhere else in the user interface because it would be
> > dangerous or rarely needed. This page is used very often by browser > > engineers during regular development and occasionally by other users
> > after reading specific documentation in advance.
> >
> > The original "about:config" page was put together in the remote past as > > the "simplest thing that works" for the use case above. At the time, > > this involved about 600 lines of JavaScript, a supporting XUL "tree" > > element, and a few predefined "alert" and "input" modal dialogs. While > > this didn't result in the most comfortable user interface possible, it > > served the purpose and we're still using it today with little or no
> > changes.
> >
> > Now we're in the process of removing XUL from mozilla-central,
including
> > the "tree" widget, and we're taking this opportunity to use standard
web
> > technologies for more of our internal pages. The practical effect is > > that we've improved the user experience of a functionality that was
> > effectively left unchanged for decades.
> >
> > When rewriting the page, however, we followed the exact same criteria: > > simplest thing that works, cheap, and easy to maintain, but without
XUL.
> > Just reimplementing the same user experience, which was a side effect
of
> > the cheapest tools available at the time, would have been unnecessarily
> > expensive today.
> >
> > One good thing with this approach is that the page can feel like part
of
> > Firefox with little effort, just by using HTML and the default styles
> > from the Photon design system.
> >
> > Also, thanks to the better web platform that we have today, the same
use
> > case can be supported using about 400 lines of JavaScript and a few > > lines of HTML and CSS, without any external UI components. For example, > > we can use HTML5 form validation to get a better user experience when
> > editing numeric values at a low cost.
> >
> > We've also added extensive regression test coverage as we progressed,
in
> > line with our usual practices, to ensure easy maintenance going
forward.
> >
> > Thanks again to Luke, Matthias, and Vincent for making all of this
> > possible!
> >
> > Cheers,
> > Paolo
>
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to