Skip to end of metadata
Go to start of metadata

Checked in 2.1 RC1

Taverna 1 name(s)

Taverna 2 name(s)

Suggestion

User opinion

Done

Available Processors (in service panel)

Available Activities (in activity palette)

Available Services

Available Services

Done

Local Services (in service panel)

N/A

Service Templates (1)

Service Templates

Done

Scavenger (in service panel)

Activities (in top-level menu)

Introduce Services (2)
Import new services

Add New Services(9)

Done

Scavenger (like WSDL scavenger)

??

Service provider

??

Done

Beanshell scripting host

Beanshell

Beanshell

Beanshell

Done

Local Java widgets

Localworker

Localworkers (3)

Local services

Done

Tools->Plugin Manager

Advanced->Software Updates

(4)

Updates and Plugins

Done

Workflow (as name for thing)

Dataflow

Workflow

Workflow

Done

Metadata

Contextual View (approximately)

X Details (5)

X Details

Done

Workflow inputs

Inputs

Workflow Inputs (6)

Workflow Input Ports

Done

Workflow outputs

Outputs

Workflow Outputs (6)

Workflow Output Ports

Done

Control link / coordinate

Condition / Coordination

Control link
Run after... (menu/details)

Coordination(12)

Done

Iteration Strategy

List Handling

List Handling

????(10)

Done

Processor (in workflow)

Processor (in workflow)

(7)

Service (11)

Done 

????

Activity (thing inside processor)

Service (8)

Service (11)

Done

Save diagram

Save diagram image

Save Diagram

Save Diagram

Done

????

Graphical Editor

Workflow Diagram

Workflow Diagram

Done

Import workflow

n/a

Merge workflow
Insert-->Workflow(in right-click when the user will have to choose nested or merge)
Import workflow (title of dialogue for choosing nested or merged workflow import)

 

Done

Annotations / Templates (RDF-like thing for Jun's thesis)

n/a

n/a


Done

Metadata (Title/description etc)

Annotations

Annotations

 

(1) It is not clear that there should be a single category that embraces Beanshell, local workers, RShell etc.  I'd go for "template services" or "service templates" that covers Beanshell etc., and "local workers" for local workers.

(2) Needs to be much less confusing.  At the moment T2 implies that you can add new activities to the workflow from this.  "Find" has implications that it can do a search.  "Import" or "Add" imply adding to the workflow.   The thesaurus has "introduce" so I suggest "Introduce Services" -> "Introduce new WSDL services" etc.

(3) It may be better to have something that indicates that it is a beanshell.

(4) No idea for the correct name.  Having it under Advanced does not seem reasonable.

(5) I've no idea why it is called contextual. I'm suggesting it go "workflow details", "service details", "input port details" etc.

(6) Maybe add "port".

(7) Katy wants "step"; KNIME use "node" (but more as service); Triana uses "task"; Kepler has "actor"; BPEL has "process"; in Pipeline Pilot the concept is not obvious.  Other possibilities are on the lines of "service player", "service enactor", "service runner".

(8) Needs to be something based on "service". Could be "service" or "service instance". I think just "service" is easiest. The distinction between a service definition and a service instance is probably meaningless for most users.

(9) This is to be moved into the Activity Palette replacement.  Its meaning there should be obvious.

(10) This has been re-opened.

(11) The users want service for processor, activity and service.  They select a service from the service palette, put the service in the workflow, connect up ports of the service, configure the service etc.  We should not make the 90%+ of cases difficult and confusing just so that it reflects the possible special cases.  Special cases should be shown up as such.

(12) Alex thinks this should be "control links" and "runs after".

Labels
  • None
  1. 2009-02-10

    (1) Like the idea of 'Service templates'.Is nested workflow 'service' going to be there as well? Are we keeping the same name or will we just call it 'workflow' which could then be inserted as nested or merged with existing (like import) upon asking the user?

    (2) Do not like 'Introduce services' very much - does not resemble anything I've seen before. Suggestion: 'Add service to palette' unless it is too long. And the user will know it will not be added to the diagram.

    (3) Localworkers can perhaps be called 'Predefined/Preconfigured Beanshells' if you want to indicate what they essentially are. I like the term 'localworkers' but it makes sense to somehow let the (advanced) user know their 'origin'.

    (4) In Eclipse and Word updates are under Help menu, which is not a very obvious place for me.

    (5) Like Alan's suggestion for using 'details'.

    (6) Agree.

    (7) What a mess. Of all suggested I like 'service runner' or 'service processor' best.

    (8) Service seems fine. And it lives inside a service runner/processor.

    1. 2009-02-16

      (1) Nested Workflow would be a service template.  It could go to workflow - I'll ask the users.

      (2) It is now  "Add New Services"

      (4) It is also under Help in firefox and thunderbird.  Why is it under Advanced?  It was under Tools in T1

  2. 2009-02-10

    my comments:
    (2) "Locate new services" ?
    (3) but is a localworker a beanshell?
    (4) seems to combine "add plugin" to "find updates for existing plugins". Eclipse uses "manage configuration" to refer to these functions
    Coordination: I'd rather have "control link" (in contrast to data link)
    (7) We have used "processor" extensively in the past, including in the formal model
    (8) service is fine as an approximation, except that an activity can be more than that – a whole sub-workflow, for example.

    -Paolo

    1. 2009-02-16

      (7) I don't see any problem with using the term processor in the formal model, the API and the serialization, but still presenting the users with "service".  There was a very strong feeling that they do not care about the processor/activity stuff.

  3. 2009-02-11

    I don't like "Service templates". I guess the idea is that they are templates because they don't work out of the box. Would not this definition also include Biomart services? Would this include the local workers? (Which were under "Local Services" in Taverna 1). I don't think they need to be bundled together - is it really important if a service is a WSDL-service or a local service?

    I don't like "Introduce services". What about "Discover services", or even better, Paolo's suggestion to "Locate new services" which implies discovery, but not adding to the workflow.  "Locate new WSDL service".. yes, I like it! (smile)

    I don't like the lonely "Beanshell" as people who have never used Beanshell would not know what it is. What about "Script (Beanshell)" ? We can add similar "Script (JRuby)" etc. later - the main point is that it's a script. If you see that you can write scripts you might be bothered to learn Beanshell, but if you don't know what Beanshell is - why would you click on that instead of say RShell? (Which is also a bad name). Or "Beanshell script" and "R script" ? ("Script (R)" looks weird.. "Script - R"?)

    I would stay with "Software updates" or something like that as it's not just about plugins.. "Updates and plugins" ? Not sure where to put it in the menu if not in "Advanced" - to we need a "Tools" menu? I think it is advanced in the sense of installing plugins, but perhaps not for checking for updates (which I *believe* is still done in the background and by updating the little green icon in the toolbar)

    About "Dataflow", I believe it's only used as the default name of the workflow, ie "dataflow5". This name should instead be related to the title set of the workflow - or simply the filename. (In Taverna 1 we had some logic that set the workflow name to the filename if it had not been set - or suggested the filename from the workflow name)

    I like the "$thing details" instead of "Contextual view".

    I agree about the Workflow input(s) and output(s) - I don't think we need "port", but we do need to seperate them from processor (or whatever) inputs and outputs.

    Coordination, control link.. difficult one. I never understood "Coordinate from" in Taverna 1 until I read the manual. I also struggled to understand what was before and after. What about "Run after completion of.." ? 

    About "local workers" - that's techie - again a user doesn't care if something is working locally, if they are preconfigured beanshells or shat - what almost all of them are is shims (difficult word), tools or utillities. That's also the way they are organized, by categories such as "list", "text", etc. Perhaps something generic like that?

    I like "Task" better than "Node". This conveys the same message as "step" - but it's easier to talk about clicking on a task, or linking together tasks. A workflow contains a set of linked tasks, realized by calling services.  Good stuff! This would also cover weird cases such as "Abstract processor" (it's just a Task where we have not yet found a service) or a future if-else-branching unit which has two or more alternative Services - it's just a Task that is branching. Tasks are performed - and you can configure how the task is to be performed, how many threads, how to retry, which services to alternate over, how task inputs are to be combined, etc.

    The reason for not using "Processor" anymore is that it was overloaded in Taverna 1, in particular with the "Available processors". Additionally it's really a Taverna-specific term.

    I like the simple "Service" and agree that we have to forget that for us the Service is on the other end of the wire. We are talking to Stian on the phone, not the voice of Stian.

    We should use "Available services" because when we add support for multiple services in a task, then you will be dragging a service on top of a task (or to it's list of services), and so it applies both for adding to an existing Task or for dropping to the workflow (implicitly creating the task).

  4. 2009-02-11

    If our motivation is to return to the original naming, shouldn't Iteration Strategy remain as Iteration Strategy rather than List Handling, though I do prefer List Handling myself and this change stemmed from requests from our users.

    One of the reasons for using Activity rather than Service was to overcome the confusion that Taverna operates only with web services. In Taverna 1 the closest equivalent was Processor Task, but this distinction between it and Processor was never apparent in the UI so it makes sense to name these Service if we want to mimic T1 naming. The terms Service and Processor were often mixed up in T1. We should avoid namings like Local Service Template, to avoid confusion with web services, maybe something like Beanshell Template or Script Template would be better.

    Changing Add to Introduce, Discover, Locate - I think this should remain as Add to be consistent with T1. Discover is what we do when we integrate BioCatalogue or Feta and isn't the same as adding a new Service directly.

    Yes we should change the Contextual View - never liked that. The current contextual view is not the equivalent to the metadata panel in T1, but this can be changed.

  5. 2009-02-11

    A slightly different issue. In the serialization format things are referred to as Activities and Processors

    http://www.mygrid.org.uk/dev/wiki/display/story/Dataflow+serialized+document

    If we are changing these things now, we would probably want to nip this in the bud now rather than later to avoid future confusion. People do like to generate/modify the XML outside of Taverna or by hand.

  6. 2009-02-12

    There are worse things to deal with than activities vs. processors in the current serialisation format.. for instance the overall complexity,  you would need to know about raven/plugin artifacts, all of the dispatch stack, and (as both me and Paolo found out) to be careful with the use of whitespace. (ie. don't push that "Reformat"-button in Eclipse!).. (smile)