Personal tools
You are here: Home → Developer → Incubation → Kepler Graphical User Interface → Archive → Implementation: Time Estimates for UI Improvements
Log in


Forgot your password?
New user?
 

Implementation: Time Estimates for UI Improvements

This page documents the changes that will be required in the Kepler User Interface code, in order to incorporate the recommended usability improvements.

Anticipated Time Expenditure on Implementing UI Improvements

NOTE: these are taken from the Consolidated Usability List of June 21, 2005 (consolidated-usability-Jun2005.doc. There are additional (potentially important) Kepler UI bugs in bugzilla that do not appear here. Please review Kepler interface bugs in bugzilla for a complete list.

 

DISCUSSION: - items marked thus need further discussion/clarification

TIME: ratings are a best guess, based on anticipated difficulty and volume of work involved (using the "how long is a piece of string?" reasoning model). Actual times may vary

  • "hours" implies 2 - 8 hours
  • "days" implies 1 to 5 days
  • "weeks" implies 1 - 4 weeks, etc

a combination implies the upper end of the first range to the lower end of the second range

e.g. "hours - days" = 6 hrs to 2 days, "days - weeks" = 4 days to 2 weeks, etc

Toolbar icons

  • should be easy - replace existing gif images with new ones, and add code to incorporate new icons for rollover/pressed states. (bug #2246) (TIME: hours)
  • icon color adjustments - Toolbar icons task (above) depends on this. Not difficult, but ~65 icons to get through. (bug #2246) (TIME: hours)

Color scheme

DISCUSSION: - Do we really want to override the default system look & feel for background colors? It would look especially odd on Mac, which uses a "pinstripe" BG under Java 1.4. Would it not make more sense to let the system manage background colors for these particular components, thus giving them the default platform look & feel? (see bug #1882)

I understand that Kepler currently has some items that are colored and others that pick up the system colors. We therefore have 2 options:

  • (TIME: days) - choose to color *all* components, per the new design, or
  • (TIME: hours - days) - remove colors from all components and allow the system L&F to manage background colors (anticipating it will be easier to remove colors, since we can search for the color-setting code, whereas adding colors will probably be much more difficult/time-consuming)

Symbology (actor, directors etc.)

New actor icons are SVG, and cannot be rendered by the current SVG framework in Kepler (Vergil). In order to enable the rendering of more-complex SVG figures, therefore, the Apache Batik SVG framework has already been incorporated into Kepler/Vergil code, but has not yet checked into CVS because the following issues need to be resolved first (see bug #2245)

  • ASSIGNING ICONS - Icons can be assigned in actor moml, or can be assigned in the actor's java code.
    • MOML - Assigning in moml means icons will show up for newly-created workflows, but *not* for old workflows. Note that some actors can't be set via moml (eg EML200 datasource), so would need to add some to java code anyway. TIME: hours - but some would still need to be added to CODE - additional hours/days?
    • CODE - Adding icon paths directly to the actors' java code (note that existing svg icons are currently defined in java code) means icons show up for all actors, in new and old workflows. Could move actual actor->svg icon mappings into a separate settings file? Or would this cause too much indirection and add complication? TIME: hours - days? Not sure how many actors
  • MEMORY USAGE - Currently, if Batik has to display more than about 150 SVG icons, it causes a JVM crash with an OutOfMemoryError. This is also an issue when showing actor thumbnail icons in the actor library, since these are rendered using Batik. So for example doing a search for a very common term that returns many actors (eg "a") causes an OutOfMemoryError. Have looked for obvious places to save memory, but now i think we're just limited by batik's memory usage. Obvious solution is to start caching icons, since many of them may be the same, yet they all get rendered from scratch (TIME: hours - days)
  • BACKWARD-COMPATIBILITY - Need to add code so old SVG icons are translated to have their origin at the top-left corner. They are currently cropped when displayed in batik, because Ptolemy's default origin for svg components is at the center of each actor icon, whereas the svg/batik standard is to have the origin at top-left. (TIME: hours - days)
  • TEXT WRAP - In EML simple example plot, text at bottom is rendered using SVG, and it does not wrap, but extends off the screen. (text did wrap in the old-style svg handling). Note, however, that if annotation actor is re-created and text is pasted in again, it *does* wrap in the new instance, so this is really just a backwards-compatibility issue (TIME: hours)
  • SMALL ICON - getIcon() method in XMLIcon works, but its success seems to be linked to the odd tree refreshing behavior described in bug #1843 (since the getIcon() method currently gets called numerous times during these rogue refreshes). When 1843 gets fixed, we may be able to make getIcon() more efficient/intuitive, and this may in turn save some memory usage (see item (2) above) (TIME: hours)

Popup Dialog Changes

dialog(s) in Kepler source - (TIME: hours per dialog?)

dialogs in PTII source - (TIME: hours per dialog, possibly hours - days for first one or two, depending how abstract the Ptolemy implementation is.)

checklist so far: (bug #2247)

  • workflow
  • director
  • actor
  • data sources
  • search Ecogrid for data sources
  • advanced search (data)
  • component sources
  • search Ecogrid for component sources
  • advanced search (component)
  • Authentication
  • semantic annotation

Menu reorganization

  • top-level menu bar (bug #2016) (TIME: hours - days? haven't had chance to delve into this code yet)
  • right-click menus- some of this goes hand-in-hand with dialog implementation - some dialogs supersede menu entries (bug #2016, bug #2247) (TIME: hours?)
  • Provide standard cut, copy, paste, delete on right click menus (bug #2011)(TIME: hours?)

Search Function

Need More Info

DISCUSSION: For the following, is Laura/anyone going to define areas to be addressed on a case-by-case basis, or should I just eyeball and change stuff as I see it when I'm doing other stuff in the code? (TIME: no estimate - task not quantifiable with current info)
  • Computer-science-centric terminology (bug #2030)
  • Use interface elements appropriately (checkboxes, radio buttons etc.) (bug #2035)
  • Information design and layout (bug #2038) (label spacing, widget grouping etc)
  • Provide meaningful error messages (bug #2015) (TIME: days - weeks??) DISCUSSION: what's the best way to do this without lots of architectural changes?
    • do we just replace the strings in the code with more user-centric ones? (most straightforward, least maintainable), or
    • do we reference error message values from a central class containing static final error-message strings, loaded from a text or xml file? A localization bundle?

Other UI-Related Bugs mentioned in the Consolidated Usability List

- should I look at any of these as priority?
  • Fix tool tips issues (bug #1844)(TIME: hours - days??)
  • Adding new port sometimes causes canvas to resize (bug #1839)(TIME: hours - days??)
  • Fix left pane re-sizing problem (is this #bug #1843?)
  • Fix copy/paste overlay problems (- what, specifically? Which bug #?)
  • Provide real-time feedback for workflow progress as a default. (bug #1911, bug #2008)
Document Actions