The SDL Appstore is growing! At the time of writing this article there are 161 apps on the store and over 220 thousand downloads from our users. This is quite impressive and we are still only getting started as the number of APIs available for developers increases. At the moment, in Studio alone we have APIs that allow a developer to do these sorts of things:
- create new filetypes (TXML), or customise existing filetypes
- create custom verification plugins (Number verifier) for QA for example
- create custom Translation Memory providers (Trados 2007 TM Provider), so you can look up translations from anywhere you like
- create custom Terminology providers (Term Excelerator), so you can use any source as a termbase
- automate your workflows using the Project Automation API (InSource!)
- create your own batch tasks, like the export to Excel batch task for example
- create custom Machine Translation providers (Slate Desktop translation provider), so you can use any Machine Translation engine
- create custom AutoSuggest providers, like the Regex AutoSuggest provider for example
- add completely new features to Studio (Qualitivity) by customising the view or adding to the ribbon
This is really great, and the best part is that all of this is possible without SDL getting involved at all. We don’t need to see the source code, we don’t have to build them into our core product. These are all plugins that you as the user can decide to use or not and the developer has complete control over so they can bug fix and add new features whenever they like. We do check the apps are safe, but this is how an API platform should work. It means you are also free to develop anything you like for your own needs and not share with anyone else, and the number of people doing this far outweighs what you see on the SDL AppStore today.
The drawback of course is that without an efficient way to manage all your plugins it can be quite a task to keep track of what you have, to test things out and remove them when done. So, we do have plans to improve all of this and they are based on two fundamental things:
- Having an easy way to install plugins
- Being able to access all the plugins you own from within Studio
The second one is harder. But this is important because if we want to be able to support the ability for a user to easily move from one computer to another and have all their plugins available without having to download and install them one at a time then we need an API to the MySDL location that can be accessed when you enter your credentials in Studio. If we don’t do this then you run into the sort of thing Emma Goldsmith described so eloquently in her blog. The good news is that we are well on the way with this… last week saw the launch of the new SDL AppStore and with it the team responsible for the development of the MySDL applications released an API to sit under the hood. This means we will be able to make a developers life better when submitting apps for the store (due to be released very soon) and we can start to think about how we build something into Studio to make your life, as the user, better as well. The really good thing is that we can do this independently of the core Studio development team and this means we can do this faster and with your help. So keep an eye on the SDL Community in the next few months because we want to involve everyone as much as we can to make sure we deliver a friendly and much improved experience for managing your apps within the Studio interface.
The first one, an easy way to install plugins has already been implemented. Initially it was released as an OpenExchange app but now it’s part of Studio 2015. It’s also been recently enhanced and provides an effective way to manage the installation and uninstallation of your plugins. If you don’t see this in the navigation pane (on the left) of the Welcome View in Studio with some of the other installed apps then you can also find it in your windows start menu under the SDL Group… so if all else fails look here:
c:ProgramDataMicrosoftWindowsStart Menu... ...ProgramsSDLSdl Plugin Management.lnk
You can copy this link to somewhere more appropriate if you like, I put it into Total Commander along with a bunch of other useful applications that run outside of the Studio environment.
The idea is this… if you need to install a plugin you just double click the *.sdlplugin file you downloaded from the app store and Studio will walk you through installing for the right version and in the right place. But if you wish to uninstall then you should run this plugin management tool. Studio needs to be closed to use the application, although you can run it without attempting to uninstall anything, and you’ll see something like this:
The interface is straightforward. First of all you get the list of plugins (not standalone apps) that are installed. If they have been developed thoughtfully they’ll contain the following helpful metadata:
- app name and brief description
- app version number
- who the developer was
- the minimum required version of Studio
You’ll also see this across the top, so depending on which versions of Studio you have installed you can select the appropriate one and this will change the list of apps displayed in the pane above:
Depending on what you have installed you might also find that some apps require Administrator rights to run successfully. These cannot be uninstalled unless you run the plugin management tool as an Administrator. So if you right-click the shortcut to the plugin manager app and run as Admin then the message will disappear and all the apps will be listed and available for uninstall. I’m currently running W8.1 so I can do this easily by searching for “plugin management” and then right-click to get this menu. Then I just click “Run as administrator”. You can probably do this from the start menu in W7… and I think in W10 too.
You then just select the app you want to uninstall and click on the “Uninstall” button for the app you wish to remove. The app does the rest.
I think this is a good step forward in the management of plugins for Studio, and I hope more developers use the sdlplugin format as opposed to creating their own standalone installers. This isn’t always possible of course, but when it is this definitely makes things easier for the user, and maybe even the developer as there is no need to create and maintain a separate installer. If you are a developer there are a couple of interesting articles from Romulus Crisan here:
Enjoy! And watch this space for more updates on improving the usability of the SDL app store in the coming months.