SDL Trados Studio
SDL Trados GroupShare
SDL Trados Business Manager
SDL Trados Live
SDL Speech to Text
SDL Managed Translation - Enterprise
Translation Management Connectors
SDL LiveContent S1000D
SDL Contenta S1000D
SDL Tridion Docs
SDL Tridion Sites
SDL Content Assistant
SDL Machine Translation Cloud
SDL Machine Translation Connectors
SDL Machine Translation Edge
Tridion Docs Developers
SDL User Experience
Language Products - GCS Internal Community
SDL Community Internal Group
SDL Access Customer Portal
SDL Professional Services
SDL Training & Certification
Language Technology Partner Group
SDL Academic Partners
SDL Enterprise Technology Partners
ETUG (European Trados User Group) Public Information
Machine Translation User Group
Nordic SDL Tridion Docs User Group
SDL Tridion UK Meetup
SDL Tridion User Group New England
SDL Tridion West Coast User Group
SDL WorldServer User Group
Tridion Docs Europe & APAC User Group
Tridion User Group Benelux
Tridion User Group Ohio Valley
SDL MultiTerm Ideas
SDL Passolo Ideas
SDL Trados GroupShare Ideas
SDL Trados Studio Ideas
SDL Machine Translation Cloud Ideas
SDL Machine Translation Edge Ideas
SDL Language Cloud TMS Ideas
SDL Language Cloud Terminology Ideas
SDL Language Cloud Online Editor Ideas
SDL Managed Translation - Enterprise Ideas
SDL TMS Ideas
SDL WorldServer Ideas
SDL Tridion Docs Ideas
SDL Tridion Sites Ideas
SDL LiveContent S1000D Ideas
SDL Contenta S1000D
SDL XPP Ideas
Events & Webinars
To SDL Documentation
To SDL Support
What's New in SDL
Detecting language please wait for.......
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 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.