SE450:G1

From Marks Wiki
Revision as of 19:49, 15 February 2008 by Mark (talk | contribs) (New page: We are to evaluate this Visual Language - https://www.se.auckland.ac.nz/courses/SOFTENG450/resources/vlpapers/AgentsheetsVL93.pdf The password and username were provided in the first lectu...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

We are to evaluate this Visual Language - https://www.se.auckland.ac.nz/courses/SOFTENG450/resources/vlpapers/AgentsheetsVL93.pdf The password and username were provided in the first lecture.

Evaluation

Strengths

  • Regularity - keeps things tidy
  • Relational Transparency - helps understanding of spacial relationships
  • Standardizes a common understanding between the human user and the computer as discrete positions on a grid will reduce the chance of errors from mismatching
  • Domain independent
  • Use of iconic graphical depictors - champion over pixel based representations Zlee003
  • Programmability of agents on reaction to behaviours Zlee003
  • Programmability of agent's behavious Zlee003
  • Can be used to illustrate semantics of flow Zlee003
  • Ability to animate agents Zlee003
  • Support for tactile programming using Visual AgenTalk (See http://jasss.soc.surrey.ac.uk/3/3/forum/1.html)
    • Even kids can build their own social environment simulations Zlee003
  • Can be used as a learning tool and collaboration tool Zlee003

Weaknesses

  • Tailoring the visual programming system to the application-domain can be more intimidating and cumbersome for more complex applications. Fig 2's example of circuits is a relatively simple one. Syan055
  • (From the looks of it) two-dimensional, would need a three-dimensional workspace for some applications that require more than just stacking agents in the same cell. Syan055
  • With gui designing tools galore, it may as well pay off to just program something directly in other high-level languages IF the tailoring process is highly sophisticated.
  • Adjacency could imply non-existent relationships between components
  • Could be over-generalized.
  • Can get messy for highly asynchronous illustrations
  • Based on Lisp - not as common as other languages like Java, C, C++ etc

=== Cognitive dimensions === zshe004

  • 1. gradient: yes, abstraction can be made - (level low, manually),
  • 2. closeness of mapping: easy
  • 3. diffuseness: very easy, user can define
  • 4. error-proneness: low, the spatial and temporal metaphors are clear
  • 5. hard mental operations: low, relatively easy
  • 6. hidden dependencies: low, clear
  • 7. premature commitment: no
  • 8. progressive evaluation: yes, can do
  • 9. role-expressivemess: yes
  • 10. secondary notation: yse
  • 11. viscosity: low to moderate
  • 12. visibility: yes.
  • 13. availability: low, platform restriction: only on Machintosh and SPARC Station

Other Literature

Presentation

Presenter

  • Daniel

Domain

  • Domain-independent
  • Style of abstraction

To Do: Figures needed

Audience

  • Visual language tool for both developers and unexperienced end users of the end product
    • Eg. Phone system
    • Eg. Circuit Simulator
    • Eg. Water-flow simulator
    • Eg. Ecology Simulations

Metaphors

  • Spacial metaphor
    • Grid-layout
    • Like a map
    • Relative position
  • Temporal metaphor
  • Shows change over time

Effectiveness

  • No figures presented in the paper. We need more literature! Zlee003
  • 3D?
  • SimCity
  • To Do: everyone to look for examples of grid based languages (1 eg each)
    • Grab Richard's slides about map versus text based directions
  • To contrast with freeform languages like raw sketching tools
  • Comparison against a spreadsheet