2012-02-09 Shortcomings of MBUI

From W3C Wiki

Shortcomings

  • Ran: dependent of the development tools (transformation)
  • Kai: no evidence of benefits in terms of SE, applicability (is it really more efficient?)
  • Jaroslav: design of UI, gap between real world, and semantic models, design oriented instead of task oriented, how to integrate design oriented approach, how to plug it in embedded components?
  • Vivian: impact in quality, is it actually more efficient? Impact in performance? and clear definition of the levels
  • Gaelle/Joelle: automatic transformations are a problem, CUI classic WIMP, but not post WIMP, enforce the separation between design time and run time, how to integrate the dependency with context, sketch task model (not true in real life), start in any abstraction level, easier sketching from CUI level
  • Jaroslav: use of stereotypes
  • Joelle: generate reverse transformation is equally important ‘specify too much to get too little’
  • Davide: control what is specified (in terms of GUI, e.g. pixel position)
  • Jaroslav: commercial apps with more ‘beautiful’ designs
  • Carmen: difficult in learning the design, learning curve to start using it, effectiveness, agile methods, SDLC with short steps
  • Jaroslav: high learning curve, and more efforts to make models consistent with design
  • Jan: separate development process, user centered design and model based approaches as an open issue
  • Javier: complex software tools, specific ones, well-defined, mature, configuration needs to be offered for these tools, modular design options or plugin-based options to define behavior for instance
  • Jan: powerful tools (instead of complex), Balsamic reference, user centered design tools,
  • Javier: tools that deal with complex transformation for example
  • Jan: synchronization, SE tools more complex than Design tools, easy to use
  • Jaroslav: business logic, controller, is the developer ready to think in terms of new concepts? Is it an obstacle? Change of paradigms?
  • Davide: rely on use cases of apps, connection points of business logic and interaction of UIs, it does not overwhelm people, but provide a framework to support the same work as previously done (as a new structure)
  • Jaroslav: formalization of previous concepts then
  • Moritz: independency of the platform, specific cases for multiple platforms, usability engineering problems, industrial cases tackle one platform at once (usually)
  • Jaroslav: lack of support of automatic transformation
  • Moritz: lots of models are necessary, manual coding to get it running,
  • Joelle: adaptation to the context of use, not only platform, but users, environments, etc…
  • Moritz: missing approach to connect context and the adaptation of the models, results
  • Joelle: how to model the value of a UI in terms of ‘joy of use’, generation of models, transformation between models
  • Jan: model quality? Survey with developers, requirement analysis, models are not always generic, collaboration among se, designers and developers (difficult communication with marketing people for instance) it is not necessary AUI targeted to certain platforms, maybe it is better to have longer development cycles, details of design are specific for GUI, platform dependent
  • Nikolaos: no UIDL that sufficiently describe users, as elderly or disabled-users, task models should support impaired users (assistive devices, etc)
  • Jaroslav: we do not have user or task models standardized, so we do not have interpreters that are consistent, accessibility of web 2.0 apps
  • Nikolaos: accessibility standards exist, but how to transform standard descriptions into a user model that could be integrated in a UIDL
  • Joelle: adaptation at run time, difficult problem, transition UIs (how to make users understand it?) how to model transitions
  • Ran: takes efforts to manage changes (e.g. for industry)


(Possible) restrictions of t he MBUI approach:

  • is there any evidence of whether MBUI is really better than traditional approaches ?
    • hard to integrate design-oriented approach starting with final interface prototype ?
  • hard to include input from a design / final UI model
    • how to plug-in dedicated/tailored UI components ?
  • models too complex -> inappropriate configuration effort
  • hard to optimize performance
  • dependent on framework / software support
  • transformations can't be derived / auto generated
  • reverse engineering: from final UI prototype to higher level models
  • task model not reflecting context of use
  • how to create task models ?
  • support starting in-between
    • support mixed approach
    • support partial models
  • fidelity of the model: pixel-exact positioning required
    • high learning curve for models + IDEs
    • integration with other approaches (user centered design)?
    • requires complex IDEs / editors, different ones or designed in modular way / extensible + powerful while easy to use tools (see Eclipse)
    • how to ensure synchronisation between models ?
  • could introduction of new abstractions (tasks etc) be an obstacle to "traditional programmers" ?
  • either not, because the concepts exist already in some (informal) way (req. docs)
    • how to overcome real-existing dependency on target platform/delivery context
    • will adaptation platforms / algorithms ever be provided ?
    • costly creation, management/updates to delivery context model
  • sensors, accuracy
  • who/how will ever define usability/pleasure of use + quality of service constraints demanding an adaptation
    • missing standard models for users with special needs
  • user model
  • how to obtain these data at runtime ?
  • task model (user aware)
    • missing full-fledged interpreters
    • adaptation needs to be explicit: show transition from state A to B
    • hard to ensure change management across MBUI levels
Retrieved from "https://www.w3.org/wiki/index.php?title=2012-02-09_Shortcomings_of_MBUI&oldid=56463"