Present:
The product development is done in Visual Studio at the moment using .Net technologies, so it's important to stay in the same set of tools. Roles apart from developers are using spreadsheets, docs and diagramming tools, photoshop to do their work.
Future:
We want to build a workflow (a sequential process with roles, queues for action items, passing on info from one role to the other, approval etc) for a product development. The software product will be in enhancement stage forever, more the reason to establish this flow.
Typical users are designers, business analysts, content creators, developers, code reviewers, testers.
Let's say a new webpage needs to be developed. It will be,
thought about by the analyst in the
tool, will enter the information in
some format
a designer will use drag and drop to
build the page look, pass it over to
the
content creator, who will add
content(help text, hyperlinks, pure
text etc) to the page
a developer will check his queue to start
building logic around this page and
make it functional.
I am thinking about Visual Studio Isolated shell to be used as a tool framework mainly due to it's IDE capabilities et al, to build this. Has anyone worked on a similar set of requirements? Any patterns/solutions/ideas around how to go about this in the VS Shell paradigm?
Update: Visual Studio Team System is already being used by the developers and testers, but there is no customized workflow for them (& analysts, designers etc) available in TFS. Also Visual Studio is not the place for non-dev users that want to do things like, - define navigation flow, design the page elements etc.
Sounds exactly like Microsoft Visual Studio Team System.
I think there is a market for this product as I could not find anything close. There are disparate tools and products but no unified IDE like experience available and needs to be built on our own.
VS Isolated Shell 2010 is the starting point and platform on which this can be built. Needs several man months and may be years. However TFS ALM application lifecycle management has several overlaps of features with this idea, although not all, because it doesn't provide a customized experience per your custom workflow.
Jury is out, needs figuring out.
Related
I keep hearing the terms low-code and no-code for development environments. I've always written code in full fledged C# environments, so this UiPath Studio UI is a bit strange to me.
Is UiPath Studio categorized as a 'no-code' development environment? A 'low-code' development environment is another term I've heard.
What categorization does UiPath fall into?
I hope this isn't considered an opinion based question
You can take the official UiPath Studio websites keywords:
UiPath Studio gives everyone from business users to advanced
developers the right automation canvas to build great software robots
—and organizations the right governance tools to manage it all.
What you have noticed was StudioX, but that is especially designed for process owners. I don't think that you really want to use that with some C# knowledge already.
Basically it gives you the possibility of no-code indeed. But that depends on what you need to achieve and how no-code is defined. Is coding starting with defining some semi-complex variables already? I would say no, but beginners might say yes, as this paradigm is not existing in a real world.
At the end it is a good mix of both. You need a control flow all the time on long processes. So you e.g. need to know how to use if-statements and that variable type checks are working different on each type. Also, if you go further and having a complex issue that can only be solved with invoking code or creating custom activities, you really need to code. Or you are lucky and find someone else's code on Go! or Connect. :)
And even further UiPath Studio is just one tool of many. What you can say is that UiPath Studio is never getting a high-level tool for specialists. It's designed for lazy RPA beginners and a little further. And that's good if you ask me.
What constitutes low-code or no-code is certainly up for debate. But UiPath themselves certainly advertise products they consider to be low-code and no-code.
UiPath StudioX
UiPath StudioX is advertised as being 'low-code.'
With StudioX, process owners like you get a no-code tool to build automations. With no-code drag-and-drop construction, a friendly interface, and pre-designed templates and scenarios, you could launch a robot on your lunch hour. StudioX Product Page
UiPath Apps
UiPath Apps is advertised as being low-code:
UiPath Apps includes a low-code app builder called App Studio. It lets you build visually appealing professional apps quickly using only a web browser through a rich library of drag and drop controls. Apps Platform Product Page
UiPath Studio
So where does UiPath Studio fit in? I'd say Studio certainly allows you to create UiPath robots with a low code approach. It's certainly not 'no-code' as even with loops and if statements you still need to add in some code like statements for the various conditions. And the ability to invoke a full fledged piece of code you've written certainly eliminates the ability to call it 'no-code.'
I think 'low-code' is a fairly accurate description of UiPath Studio.
I have been searching for UI prototype tools which requires little/no coding, along with decent UI features. In one project, I would like to be able to implement a drop down list which the user picks a choice, which can affect the list of choices shown by another drop down list. Mind me, I am fairly new to UI/UX design and web design. And no, I would not like to use HTML due to its inflexibility and it being difficult to modify/extend. Any suggestion of good UI tools, whether be it free or paid?
Probably should try using Microsoft Visual Studio Community or Enterprise. Community is the minimum but Enterprise has much greater number of benefits. Then, get the web development workload in order to use ASP.NET to develop the type of form you intend to get.
The question says it all, we know most of the hosted web-based UI prototyping tools out there, but we would like to have ours hosted on our own internal servers, preferably with on-line multi-user collaboration functionality (i.e. users modifying the prototype, making comments, etc. in parallel).
Any suggestions will be appreciated.
Sketchflow (in the top-end version of Expression Blend from Microsoft) meets almost all your criteria. It ain't cheap, but it is very powerful.
The deployment package of a Sketchflow build can just be placed on an internal server (no IIS required to deploy).
Multiple users can overlay their comments and pen drawings over the top of the screens. Their feedback is packaged as a unit and sent back. All feedback can then be loaded back into the Expression Blend project and the feedback from 1 or more users viewed overlaid on the correct screens.
It does not meet your multiple-user authoring requirement though, but as they say "too many cooks...".
Most tools are either desktop based or hosted. Seen very few which offer a downloadble multi user version. iRise is one choice with the editor as a desktop product and a centralized server for sharing among users. The budget is typically from $50K to $250K. A similar option exists for Serena composer as well, not sure of the price though.
Both iRise and Serena are not real collaborative tools, the central server is only for sharing the finished prototypes and getting feedback.
If the requirement is for a completely web based multi user tool then 10screens can be an option - http://www.10screens.com. The same product available on the site in a hosted mode can be downloaded and installed on your own servers.
We are in the process of implementing the sharepoint application, we would like to know the the pros and cons of SharePoint workflow versus Windows workflow.
Workflows in SharePoint are implemented using the Windows Workflow Foundation, so they are not that different, but there still are some things to be aware of regarding that implementation.
SharePoint is a Windows Workflow host, so you don't have to implement your own host which is fine if you agree with the decisions made by the SharePoint team:
Workflow instances are persisted in the content database
Communication with the user is through SharePoint tasks
Every workflow instance is tied to a list/library item
Tracking is not implemented
If these choices are to your liking then by all means use the SharePoint workflows.
If not then implement your own host and make your own decisions.
They are the same thing. The current Windows Workflow Engine was created for SharePoint.
Now it should be noted, that the Workflow engine is going to be overhauled with the release of .Net 4.0. I don't know the specifics, but I've been told the differences are significant. I woudld assume this is going to be used in Sharepoint 2010, but I don't have any information on that.
Here is a link describing the upgrade in 4.0.
You haven’t specified whether you’re building a custom coded application in SharePoint or configuring an out of the box solution via the browser. Either way, here are a few options for workflows in SharePoint.
Use the native workflows built into SharePoint and readily accessible from any list. They’re very basic (mostly simple approvals with one or two steps), but they’ll get you up and running very quickly and it can all be done via the browser.
Use SharePoint Designer to build slightly more complex workflows. This will give you access to conditional logic (i.e. route a workflow based on a list value) and unlimited steps and well as a number of other features that allow you to introduce more logic into the process. The downside is you have to work with SharePoint Designer which, to be frank, can be a real pain.
Custom code your workflows in WF. Windows Workflow underlies the first two options which are essentially abstractions on top of the underlying framework. The main difference with this approach is that you’re not limited to the functions that the browser or SPD surface. The downside is that this becomes a more complex process (although admittedly the workflows will likely be more complex) and you have to go through the rigmarole of coding against SharePoint, packaging deployments, publishing, etc.
I find the best balance in terms of ease of development and functionality is to try and work through the above list in the order I provided them and only progress to the next option if you definitely can’t implement the requirement with the current point.
It's basically the same technology. If you know one you can easily work with / switch to the other.
When you add the SharePoint dll to your solution you get some specific SharePoint 'activities' that you can use in your workflow. (create task, ...)
Your SharePoint Server will act as a host for your workflows.
The best way to deploy a workflow in SharePoint is by using a SharePoint feature. This tells SharePoint what dll (assemblies) to use and which (input) pages to show.
As input pages you can use simple .net aspx pages or infopath forms. Both require some trial and error to get the hang of it.
SharePoint simply uses windows workflow Foundation (WF) as its workflow engine. WF in itself is just a generic workflow engine.
In order to use WF you must implement a host process for the execution of workflows, and configure it so it persists instances to database etc (these days most people use a WCF service as a workflow host, see here or here).
SharePoint comes with everything already configured and implements its own workflow host, so you can start using workflows out of the box. Apart from that, it comes with custom activities and other goodies specific to SharePoint.
As stated in other answers, they are the same, as they use the Windows WOrkflow Foundation. That being said, there is a major thing to keep in mind when it comes to Workflows created through SharePOint Designer: They are not "portable" out of the box, meaning that you can create one bound to list a, then save the list as a template and then create another list based on that template, the workflow will NOT work (you have rebind it as it is still referencing the original list's id (guid).
Microsoft Team System appears to be a great platform for process-oriented systems implementation, however if you strip out access for the BAs, PM and Business Users and just purely use it within a Dev team does it have any more value than just using Visual Studio Professional, SourceSafe, a Defect Tracking Tool and a continuous integration server like CruiseControl or TeamCity?
Yes. Every replacement technology you've mentioned is something that is supported by the Team System package (either in this release or the next). All of these components are designed to integrate and work with each other in TFS. This is a high priority of the TFS team for all components. The result is a set of features which in most cases seamlessly integrate with each other.
I'm not familiar with several of the other projects you mentioned but it's unlikely that they integrate as well with each other as the corresponding TFS components. This is not to say they have no integration or perform poorly as products. Just that they are not designed ground up to work with each other. Hence the interaction will not be as crisp as the TFS components.
Is this valuable enough to continue using TFS? Don't know because it would be highly dependent on how much you value this integration.
One of the big selling points for TFS for my team is the coherency it provides to our overall product life cycle. We do allow BAs, PMs and Business Users to have certain levels of access to TFS, but even if we did not, the product would still be of great value to use. The ability to manage our workflows within TFS and enforce consistency across the development team is great.
Some of the features that TFS provides that we use: security, reporting, work flow management, integrated builds, email alerts, branching / merging.
Could you pull it off with a hodge-podge of other tools? Probably, but it wouldn't be as easy to manage and maintain and you probably wouldn't be able to pull out the kind of data necessary for reporting and tracking the way you can with TFS.
On a sidenote, if your counting on Visual SourceSafe as your repository I would highly suggest looking elsewhere. From personal and business experience, I can attest that it cannot be counted on as a stable/robust repository.
My thoughts.
Sure it has value. There are a ton of client features only in the Team SKUs (don't let the name fool you -- they are primarily just the new "super premium" kitchen-sink versions, that also have the nice bonus of including a server CAL for TFS.) Exact specs available here: http://www.microsoft.com/visualstudio/en-us/products/teamsystem/default.mspx
Looking specifically at the collaboration features, again there's clear value in a system whose components were design to "just work" with each other. The setup is streamlined (though it has a ways to go); the UIs are consistent and accessible from each other; the backend feeds a unified reporting/analysis service. If you have a large team, the overall perf/scalability also far exceeds what the typical OSS suite is capable of at the moment.
The question is whether it's worth the $$ to you. Why use Visual Studio Professional instead of SharpDevelop? Why SourceSafe instead of Git? Why not Notepad and specially labeled folders?
All of the commercial products are commercial for a reason (ok, maybe not SourceSafe!). If you want something with a broad feature set, tight integration, well-defined support & testing lifecycle, good fit & finish, etc then it's usually worthwhile to spend the $$ and let your development staff get on with their work. If you don't mind doing setup & troubleshooting yourself, switching between several applications as part of the development workflow, losing the ability to query & report on team statistics as a whole, etc then by all means go open source -- many OSS dev tools are very solid nowadays.