Evzen Polenka I know PS can have GUIs and can be run as an exe but I've personally never seen an application done like that (maybe it's just me).

I'm huge advocate to use whatever it make sense for you to fulfil your needs. In your situation given your knowledge and experience I perfectly understand why a solution which involves scripting and  command line parameters is better and faster than what you have OOB. Please keep in mind that while clicking might not be the best experience you can get in some situations neither a solution which requires passing command lines parameters is appropriate for a casual user. It might be for you and other people with IT background but not for the majority of users.

You're saying that putting things closer to the user doesn't mean is it has to be a plugin. I prefer to do my activities inside an application rather than switching between multiple applications (Microsoft Visual Studio is considered to be probably the best code editor exactly because of this reason). So for example rather than creating a separate application that can nicely handle 36 packages I would prefer to have that options seating alongside the default open package option within Studio ribbon. That gives me the opportunity to assign a shortcut if I want which gives allows me to start the process by touching just 2-3 keyboard keys.

I'm not trying to say you're wrong Evzen Polenka it's just that I see this topic form a different angle.

With my article I wanted to project the potential result you can get with this options and what has the potential of making the customisation more usable and simple for the casual user. It's not meant to be an evaluation from pure technical standpoint. Also I don't believe in silver bullets so as I said in my article if there is a good reason for the standalone application than it's absolutely fine, in fact we've just done that recently.

Problem is that what you say is not what I see in the article. The article feels like it describes differences between plugins and standalone application IN GENERAL, not from the perspective of "how good/bad can those be handled by the current architecture of appstore, etc.". So yes, I might have missed this point... since I couldn't recognize the point in the article.

Regarding handling applications in appstore - what exactly should be that problematic? Downloading is the same, changes notification is the same as well... Okay, in such case some unified installer would be handy, what is the problem with that? Some pre-configured "installer template" which installs all applications to a same place (similarly to plugins), puts Start menu links in the same place, etc. Of course that "same place" where the applications would be installed would need to be added to PATH, so that one can run the application from anywhere (as one would expect), etc. I don't see that as a showstopper... but I admit that I may be well missing something since designing such architectures is not my primary job.

Evzen, I think you're missing the point.  The article was written to explain the difference between the use of a standalone tool and a plugin, and in particular how we will be able to handle these efficiently when we integrate the appstore into Studio so that the management of these apps is simplified.

Perhaps you could offer a solution to the management of apps developed by many different developers so that there was a consistent way for users to download, upgrade, get notified of changes etc.  If you did that I'd be more interested in what you have to say.

Romulus, it looks like you missed my point completely.

First, I was mentioning the Powershell Toolkit simply as an example of "non-plugin thing" which apparently does NOT need to be deployed in Studio application folder and still works without problems (as opposed to your claims in the article).

This has absolutely nothing with PowerShell requiring IT knowledge or not. And while we are at that, RUNNING PS scripts does not require any it knowledge at all... just as RUNNING any application doesn't.

Maybe you think that PS scripts have to be run only from PS console, or so... that's simply not true. Not only it's possible to run PS script e.g. using a simple hybrid batch file (which is BTW what I use in my enhanced PS Toolkit), but PS scripts can be even compiled to standard executables, with normal GUI etc., so user doesn't even know that he's running PS script.

I'm not against plugins as a concept, when it makes sense... but I'm against nonsensical forced integration of everything just because someone finds it cool and wants to make a buzz about plugins.

Putting things closer to users does NOT mean to make everything a plugin...

You want to make things easier to use? Then fix the poor UX and some long-standing design flaws in the first place... stop leaving things half-baked and unfinished...

I mentioned applications depending only on libraries already present in OS to contradict your claim that standalone application MUST have an installer. Sure, complex applications MAY (and most of them do) need own installer, but it's definitely not a must. Especially if we are talking about small application which may be essentially just calling a few Studio API functions.

This leads me to my example of why I do not want Studio plugin, but standalone application - because I do NOT want to click million times to do my stuff. I want my actions to be scriptable - e.g. to create a project using info parsed in the form of plain text (list of languages, project location, TMs location, etc.) from some external system and passed to this application as command line parameters... and the same for e.g. importing translation packages - did you ever tried to import like 36 return packages MANUALLY ONE-BY-ONE (which is the only option in Studio - ref. above to the part about poor UX)? I better use the script to tell Studio "import all packages located in C:\foo into project located in C:\bar" and that's it! Why would I bother clicking through some GUI to export target files if it can be done easily using command like "ts et c:\bar d:\export" (which can be stored in a script, so I can do it using a SINGLE push on Enter)?

Seems to me that people are so degenerated by all the clicking and taping and scrolling that they don't know anymore what "effectivity" is and means :(

Romulus Crisan (former member)  Right-click context menu that creates project, opens Trados Studio and then editor view. That pretty much automates the entire process. Also, want to quickly produce very small apps (console app) for very specific jobs and protyping/experimenting with the api.