Shell Extensions in the Future
Shell extensions are an easy way to customize the GNOME experience. Currently we receive about three extension updates per day (that's three releases) via extension.gnome.org (e.g.o). Most of the changes need manual approval, which can be a tedious process, but we're happy to have such an active community.
Extension development has a low barrier to entry and is an important tool for reaching out to the community and also to developers who find their first GNOME work here and might go on to become core developers for GNOME.
The support for extensions within our community has, since the 3.0 release, always been a question of heated discussions. Of course we want to provide a streamlined GNOME experience and using extensions is "the wild west" as far as a designed and optimized user experience goes but looking at the sheer number of extensions and extension users, we're on our own clearly not providing for the needs of our users.
Extension Plugin
Within the next few months, the Firefox-plugin that is used to install extensions via e.g.o will no longer be supported. While gnome-software has a mechanism to install extensions, it currently is missing functionality to browse the content e.g.o provides.
There are three major ideas to handle extension interaction in the future:
- Let e.g.o be without the functionality to install or manage extensions. This would leave it as upload-only platform and is only useful for developers. Full functionality is restored via gnome-software.
- Pro: A hopefully streamlined browsing and searching user experience via gnome-software
- Con: We would lose the interaction on e.g.o. Many blogs, users, fansites post about GNOME extensions using canonical links to e.g.o from where extensions can be installed. All this interaction would be lost. People would need to copy/paste extension names to gnome-software. Also lots of work for gnome-software
Develop an alternative browser plugin with feature parity to the current one that will be deprecated soon. There already is an effort to do this
- Pro: The user experience doesn't change. no additional work in gnome-software
- Con: There might be technical hurdles beyond the missing browser functionality that prevents the plugin's usage
Identify extensions using a URI-handler. This is used to link extensions on e.g.o with its page in gnome-software, which then can be used to install the extension. https://bugzilla.gnome.org/show_bug.cgi?id=772577
- Pro: The user experience changes slightly but e.g.o can still be used to install extensions (in a way), minimal additional work in gnome-software is required
- Con: We let the desktop environment handle connecting e.g.o and gnome-software, which might be a problem for casual users with older installations
Extensions Need Our Help
Extensions are an important part of the GNOME ecosystem and we're not giving them much love. While the most popular extensions change some specific part of the UI to be more like a user is used to or likes, the second most popular extensions are indicator-style extensions. Those extensions add an indicator to indicate weather, the current workspace, whether there are updates available, and so on. This functionality could (in the weather-case, for example) be provided by core apps or we could help developers of these extensions with some design help. We can give out guidelines for extensions developers on how to design indicators and which interactions could be useful.
A second big extension family are extensions that add to the status area. Users are provided with additional functionality like shutdown-timers, better (application based) volume control, etc.. The placement of these extensions in the menu is often a result of pure chance and some heuristic the extensions employ. Here we should give developers guidelines on where and how to place additional entries so that entries we want to be kept together are kept together. We can give help on where to place these additional items and where they should be in relation to others.
A lot of extensions have quite a few translations. This is amazing, given that most extensions are translated by drive-by contributors, without any organizational help. For the most popular extensions we can surely give a little bit of help translating extensions to improve the user experience for those people that do not speak one of the major languages of the developer communities.
At last, extension development and the interfaces are documented very poorly. It was impossible for this author to find help on doing OAuth (maybe even using the gnome-online-accounts) or xml-parsing within a shell extension. Either this functionality is missing (which isn't good) or it is there and nobody has been able to find it. Here we can do better work that will allow developers to augment the shell experience.
If we give proper support to the extension developers, we could get them to become ambassadors for GNOME for people that believe we're taking away their freedom to choose. Having a good relationship with those developers helps us collect gnome-shell and gjs know-how to gain useful resources for our future endeavours.