Re: Cas Viewer discussion

[Jörn Kottmann <ko...@gmail.com>]

> Good suggestion to have a new plugin to switch the underline tools  
> (CAS
> Editor or CAS Viewer). We just provide some customization (through  
> Eclipse
> preference ?) for users to select what is the "default" mode they  
> would like
> to have since different users may have different usage pattern.
>
> Actually, we did take this "integrated" approach to have only ONE  
> tool to
> edit UIMA component descriptors and the "deployment descriptor" used  
> in
> UIMA-AS deployment. That is the CDE which is used to edit all UIMA XML
> descriptors.

Actually for the Cas Viewer case we need two plugins.

1. One plugin which contains editors which can show and manipulate
a CAS file. This would be for now the CAS Editor and the CAS Viewer,
later also the CAS journaling.

2. In your case a new plugin which takes care of searching the type  
system
in the users project folder and providing style information. The type  
system
and style information are then passed to the first plugin to open the  
actual
editor.  The users chooses which editor is preferred with the eclipse  
default editor
setting for CAS files. I think we can call this uima dev plugin.
This plugin can also include other parts like support to execute
an AE, log viewer, or whatever.

> Also, we plan to use the same approach to "extend" the CAS Viewer to  
> support
> CAS journaling as described in the Wiki. Any comment or suggestion  
> about
> this debugging tool will be appreciated.

Sure would be cool to have something like this.

Actually I think the story here is how to compare two snapshots of a  
CAS.
First you have to choose what should be compared, I think we can do this
like the "Compare with ..." menu.
Then we show some kind of structural compare, what was added,
what was removed, what was changed, etc.

For editing it would be nice to maintain a history of changes in the  
CAS file.

> Users that use CAS Viewer are also editing or debugging their Java/ 
> Plugin
> perspective (CVD gives us a good example of "Run, Debug code, and  
> Inspect
> CAS"). The primary usage of CAS Viewer is to inspect the CAS after  
> running
> their analysis engine. Because of that, they prefer not to have  
> "many views"
> floated around. By encapsulating the information into one tab, it is  
> easy to
> hide the CAS Viewer. This approach can be easily changed since the CAS
> Viewer is modular and is composed of UI parts. But, until now, I  
> don't get
> any feedbacks to be in this way (having multiple views to show  
> different
> information).

I think this is the most important part of the discussion here. It  
would be much harder to share
common code between the CAS Editor and the CAS Viewer if we have to  
support both ways.

Developers are used to switch perspectives in eclipse for many tasks.  
If you write
code and debug it, you already have to switch between Java and the  
Debug perspective in short cycles.
If they now have one more perspective to view a CAS this does not  
makes a big
difference anyway.

I still think that the huge benefit of doing it the Cas Editor way  
with multiple views:

+ The Cas Editor and Cas Viewer can share views and other stuff easily.

+ Its easier to explore a CAS file because there is more screen space  
to see things.

+ We always say UIMA is universal and not only for text. We should  
follow this design
decision also in the ui tools. With multiple view it is easy to  
visualize sofas of any type
because the views can just be reused, e.g an image cas would be  
displayed in an
image viewing editor and the feature structures, etc can be viewed in  
the already existing
views.

+ External developers can reuse our views to create something new.

+ Its more flexible, users and developers can arrange views as needed  
from case to case.

Jörn

Re: Cas Viewer discussion

[Jörn Kottmann <ko...@gmail.com>]

On Aug 15, 2008, at 6:07 PM, Tong Fin wrote:
>> Here an example:
>> The student Marco Nehmeier told us that he has written a tool to  
>> view and
>> annotate html with eclipse his task would have been easier if he  
>> could
>> have just reused our views for cas specific things other than  
>> displaying
>> the html with annotations.
>>
> I think the issue here is how and what we mean "share the code". For  
> me,
> there are  two levels to share the code:
> - Level-1: sharing UI classes (corresponding to Eclipse's
> Control/Composite)

Building a library with UI classes which are used by the Cas Editor and
Cas Viewer will take a huge amount of time. During building
the library the extracted classes must be integrated in to both tools.
In some places this will mean just to rewrite something to make it work
with the new library. This is also true for our standalone UI tools.

> - Level-2: sharing UI classes and their containers (corresponding to
> Eclipse's Section, Page, Editor, View, etc)
> I think the Level-1 is the most flexible way since it allows  
> different tools
> to have its own way how to display the content. Some tools may use  
> Section
> as the container (e.g., CAS Viewer) and others may use View (e.g., CAS
> Edtior).

Yes Level-1 sharing is flexible but we cannot share everything at  
Level-1.
The views in the Cas Editor synchronize to display more information  
about
something that is selected. This behavior for example could not be  
shared
at Level-1.

> Marco Nehmeier prefers to have the sharing at Level-2. With Eclipse,  
> this
> can be done
> easily based on the Level-1 sharing.

Maybe it is easy but it will still take an extensive amount of time to  
write all the
views with using the ui library. Just reusing existing views makes it  
possible
to reuse more code.

The cas editor specifies how to get the CAS from the current editor  
and then the views
can visualize the cas in every way they want. A new editor which does  
html for example
only has to use the same interface for providing the cas to the views  
and the views can be
reused by adding them to the workbench.

This models makes it simple to extend it either with new editors or  
with new views.
The advantage here is that a developer can just concentrate on the new  
views or
editors he wants to write.

> BTW, I think we should start to summarize the issues and list the
> opinions/suggestions so far.

We should first make a decision if we split the Cas Viewer into  
multiple views or not.

Beside this I would like to start to extract the editing part of the  
Cas Editor and put it into an eclipse plugin.
We can start working on a uima dev plugin which contains the code from  
the Cas Viewer to locate a type system.
Then we will define an API to open a eclipse editor which has a CAS  
object as input. This can then be used by the
Cas Editor and Cas Viewer independent form how we make the decision  
above.

Jörn

Re: Cas Viewer discussion

[Tong Fin <to...@gmail.com>]

On Fri, Aug 15, 2008 at 3:25 AM, Jörn Kottmann <ko...@gmail.com> wrote:

> I don't mean that.
>> From the end-user's point of view, it is a good idea for users to "see"
>> only
>> one tool (like the way users edit the UIMA-AS Deployment Descriptor).
>> Under
>> the cover, it may switch to View mode or Edit mode according to some
>> preference or setting (or dynamically switch).
>> The question here is what is the UI of View mode and Edit mode. That is
>> the
>> subject of the discussion.
>>
>
> Viewing a CAS is much more complicated than viewing an xml file in
> a structured editor. There are problems which can not be solved
> with the structured editor like supporting different sofa types and
> reusing the code in eclipse based cas tools.

Usually, the structured editor uses Sections, and Pages to group and
seperate to information to be displayed. I don't understand how the
"multiple views" can have a better support for different sofa types. For
example, if the type is text and the sofa type is image, the section that
displays the text will display the image. If there is a type that the tool
cannot understand/display, that section will not be shown or empty.


> Here an example:
> The student Marco Nehmeier told us that he has written a tool to view and
> annotate html with eclipse his task would have been easier if he could
> have just reused our views for cas specific things other than displaying
> the html with annotations.
>
I think the issue here is how and what we mean "share the code". For me,
there are  two levels to share the code:
 - Level-1: sharing UI classes (corresponding to Eclipse's
Control/Composite)
 - Level-2: sharing UI classes and their containers (corresponding to
Eclipse's Section, Page, Editor, View, etc)
I think the Level-1 is the most flexible way since it allows different tools
to have its own way how to display the content. Some tools may use Section
as the container (e.g., CAS Viewer) and others may use View (e.g., CAS
Edtior).

Marco Nehmeier prefers to have the sharing at Level-2. With Eclipse, this
can be done
easily based on the Level-1 sharing.


>
> In my opinion there is not a big difference anyway between showing
> the CAS in a structured editor or in its own perspective with multiple
> views,
> but the second way has a significant advantage about the first one.

I think we need some use-cases to understand the benefits before we decide
which way to go.


>
> We can share and reuse our code.

Agree. I prefer the two-level approach of sharing as I described above
(also, based on how other internal tools embedded the CAS Viewer).


> The advantage we have if we work
> together on new features outweigh the advantage of viewing text based
> CAS a little faster without switching perspective.

Agree. That is why I have the tendency not to use a different "persepective"
unless we have a strong requirements.


BTW, the user
> can just open a CAS Viewing editor in the java perspetive and inspect
> it with only the Outline view. This will be enough for some task,
> for deeper inspection he can than switch.
>

Yes, "quick inspection" is a good idea. In Eclipse, Outline view has a
well-defined behavior.  We may need our own view. In some cases, "quick
view" (a pop-up view) may be good enough.

BTW, I think we should start to summarize the issues and list the
opinions/suggestions so far.

Re: Cas Viewer discussion

[Eddie Epstein <ea...@gmail.com>]

Unless I missed it, an important area of discussion are the various scenarios
using CAS Edit/View functionality. In my own experiences, switching back
and forth between looking at a CAS and looking at annotator code,
descriptors and type systems is the most common.

The CAS viewer, fitting into a single pane, easily integrates with these
using the Java perspective. Would the same be true integrating these other
objects into a CAS perspective?

Eddie

On Fri, Aug 15, 2008 at 3:25 AM, Jörn Kottmann <ko...@gmail.com> wrote:
>> I don't mean that.
>> From the end-user's point of view, it is a good idea for users to "see"
>> only
>> one tool (like the way users edit the UIMA-AS Deployment Descriptor).
>> Under
>> the cover, it may switch to View mode or Edit mode according to some
>> preference or setting (or dynamically switch).
>> The question here is what is the UI of View mode and Edit mode. That is
>> the
>> subject of the discussion.
>
> Viewing a CAS is much more complicated than viewing an xml file in
> a structured editor. There are problems which can not be solved
> with the structured editor like supporting different sofa types and
> reusing the code in eclipse based cas tools.
>
> Here an example:
> The student Marco Nehmeier told us that he has written a tool to view and
> annotate html with eclipse his task would have been easier if he could
> have just reused our views for cas specific things other than displaying
> the html with annotations.
>
> In my opinion there is not a big difference anyway between showing
> the CAS in a structured editor or in its own perspective with multiple
> views,
> but the second way has a significant advantage about the first one.
> We can share and reuse our code. The advantage we have if we work
> together on new features outweigh the advantage of viewing text based
> CAS a little faster without switching perspective.  BTW, the user
> can just open a CAS Viewing editor in the java perspetive and inspect
> it with only the Outline view. This will be enough for some task,
> for deeper inspection he can than switch.
>
> Jörn

Re: Cas Viewer discussion

[Tong Fin <to...@gmail.com>]

>
> In addition, I tend to rearrange the views in a perspective to suit
> my needs.  I like some views stacked, others get their own area.
> My workspace will remember those changes for me.

I do the some way as you. This is the way that Eclipse User Guideline
recommends.

I don't think you
> can do these sorts of things with a single, integrated editor.

It depends on the contents. There are some cases that the users cannot
"freely" arrange the views. For example, the "details" part in the
"master/details" block in a form editor (in CAS Viewer, Plugin/Manifest
Editor, etc.), is tight to the "master" part. Eclipse's Form recommends some
way on how to arrange those parts.

So all in all, it's just much more flexible to have several views,
> and to unite them all under a (optional) perspective.
>

We should try to estimate the efforts and go through some screen-mockups by
using some use-cases.

-- Tong

Re: Cas Viewer discussion

[Thilo Goetz <tw...@gmx.de>]

Jörn Kottmann wrote:
>> I don't mean that.
>> From the end-user's point of view, it is a good idea for users to
>> "see" only
>> one tool (like the way users edit the UIMA-AS Deployment Descriptor).
>> Under
>> the cover, it may switch to View mode or Edit mode according to some
>> preference or setting (or dynamically switch).
>> The question here is what is the UI of View mode and Edit mode. That
>> is the
>> subject of the discussion.
> 
> Viewing a CAS is much more complicated than viewing an xml file in
> a structured editor. There are problems which can not be solved
> with the structured editor like supporting different sofa types and
> reusing the code in eclipse based cas tools.
> 
> Here an example:
> The student Marco Nehmeier told us that he has written a tool to view and
> annotate html with eclipse his task would have been easier if he could
> have just reused our views for cas specific things other than displaying
> the html with annotations.
> 
> In my opinion there is not a big difference anyway between showing
> the CAS in a structured editor or in its own perspective with multiple
> views,
> but the second way has a significant advantage about the first one.
> We can share and reuse our code. The advantage we have if we work
> together on new features outweigh the advantage of viewing text based
> CAS a little faster without switching perspective.  BTW, the user
> can just open a CAS Viewing editor in the java perspetive and inspect
> it with only the Outline view. This will be enough for some task,
> for deeper inspection he can than switch.
> 
> Jörn

In addition, I tend to rearrange the views in a perspective to suit
my needs.  I like some views stacked, others get their own area.
My workspace will remember those changes for me.  I don't think you
can do these sorts of things with a single, integrated editor.

Sometimes I use the perspectives that are offered, sometimes I don't.
For example, I never use the Team perspective, I just have the
subversion views open as part of my Java perspective.

So all in all, it's just much more flexible to have several views,
and to unite them all under a (optional) perspective.

--Thilo

Re: Cas Viewer discussion

[Jörn Kottmann <ko...@gmail.com>]

> I don't mean that.
> From the end-user's point of view, it is a good idea for users to  
> "see" only
> one tool (like the way users edit the UIMA-AS Deployment  
> Descriptor). Under
> the cover, it may switch to View mode or Edit mode according to some
> preference or setting (or dynamically switch).
> The question here is what is the UI of View mode and Edit mode. That  
> is the
> subject of the discussion.

Viewing a CAS is much more complicated than viewing an xml file in
a structured editor. There are problems which can not be solved
with the structured editor like supporting different sofa types and
reusing the code in eclipse based cas tools.

Here an example:
The student Marco Nehmeier told us that he has written a tool to view  
and
annotate html with eclipse his task would have been easier if he could
have just reused our views for cas specific things other than displaying
the html with annotations.

In my opinion there is not a big difference anyway between showing
the CAS in a structured editor or in its own perspective with multiple  
views,
but the second way has a significant advantage about the first one.
We can share and reuse our code. The advantage we have if we work
together on new features outweigh the advantage of viewing text based
CAS a little faster without switching perspective.  BTW, the user
can just open a CAS Viewing editor in the java perspetive and inspect
it with only the Outline view. This will be enough for some task,
for deeper inspection he can than switch.

Jörn

Re: Cas Viewer discussion

[Tong Fin <to...@gmail.com>]

On Thu, Aug 7, 2008 at 6:01 PM, Adam Lally <al...@alum.rpi.edu> wrote:

> On Thu, Aug 7, 2008 at 5:16 PM, Tong Fin <to...@gmail.com> wrote:
> > For the CAS Editor, editing a CAS is a tedious operation that can take
> long
> > time, for example, when users try to create "gold standard" CAS files. It
> > may make sense to have it own perspective for the CAS Editor.
> >
>
> Are you suggesting, then, that the CAS Editor and CAS Viewer should
> not be integrated into a single tool?
>
>  -Adam
>

I don't mean that.
>From the end-user's point of view, it is a good idea for users to "see" only
one tool (like the way users edit the UIMA-AS Deployment Descriptor). Under
the cover, it may switch to View mode or Edit mode according to some
preference or setting (or dynamically switch).
The question here is what is the UI of View mode and Edit mode. That is the
subject of the discussion.
Since it is a difficult issue, I prefer to do step-by-step toward the full
integration.

- Tong

Re: Cas Viewer discussion

[Adam Lally <al...@alum.rpi.edu>]

On Thu, Aug 7, 2008 at 5:16 PM, Tong Fin <to...@gmail.com> wrote:
> For the CAS Editor, editing a CAS is a tedious operation that can take long
> time, for example, when users try to create "gold standard" CAS files. It
> may make sense to have it own perspective for the CAS Editor.
>

Are you suggesting, then, that the CAS Editor and CAS Viewer should
not be integrated into a single tool?

  -Adam

Re: Cas Viewer discussion

[Tong Fin <to...@gmail.com>]

On Thu, Aug 7, 2008 at 4:24 PM, Adam Lally <al...@alum.rpi.edu> wrote:

> On Thu, Aug 7, 2008 at 12:05 PM, Tong Fin <to...@gmail.com> wrote:
> > The approach taken by the CAS Viewer is not new. The GUI design of the
> CAS
> > Viewer is based on "multiple-page form editor" like plug-in/manifest
> editor.
> > In CAS Viewer, each page corresponds to each CAS view (sofa). In each
> page
> > (or CAS view), I use "sash form", "master/details block", and "sections"
> to
> > represent/separate the logical structure of the CAS and to show the
> > relationship and interaction between parts. For example, when user
> selects
> > some "type" in the "CAS Types" section, the annotations of that selected
> > type will be highlighted in the "Document" section.
> > These sections are very related with each other. I don't see much benefit
> > from moving from "section" to "view". If we have "multiple-view"
> > (multiple-sofa) in the CAS, the situation becomes more complicated.
> >
>
> Okay, from a real-estate perspective, I guess there is not that much
> difference between the two approaches.  I think the main point of
> having a perspective with multiple views or editors is exactly to
> support integration of different components (views and editors).  That
> seems to be exactly the situation that we're in now with the CAS
> Viewer and CAS Editor.  Wouldn't it be easier to mesh the different
> parts of the Viewer and Editor if they were separate views/editors?
>

About "Perspective", I look at the Eclipse's User Guideline at:
    http://wiki.eclipse.org/User_Interface_Guidelines
The recommendation is to think "carefully" before creating a "new"
perspective.

*Guideline 8.1
*Create a new perspective type for long lived tasks, which involve the
performance of smaller, non-modal tasks.

We need to think about how users will use CAS Viewer and CAS Editor. My
thinking is that they will use the CAS Viewer when they are developing or
debugging their Java codes which are in Java or Debug perspective. The time
they spent with the CAS Viewer is "short" (a "short task") so it may not a
good idea to have the CAS Viewer in its own perspective.

Another suggestion from the Guideline is that, before switch to the new
perspective, always ask the user which can create an extra overhead.
*Guideline 8.7*
A new perspective should be opened only if the user explicitly states a
desire to do so. In making this statement, the user agrees to leave their
old context, and create a new one.

For the CAS Editor, editing a CAS is a tedious operation that can take long
time, for example, when users try to create "gold standard" CAS files. It
may make sense to have it own perspective for the CAS Editor.

-- Tong

Re: Cas Viewer discussion

[Adam Lally <al...@alum.rpi.edu>]

On Thu, Aug 7, 2008 at 12:05 PM, Tong Fin <to...@gmail.com> wrote:
> The approach taken by the CAS Viewer is not new. The GUI design of the CAS
> Viewer is based on "multiple-page form editor" like plug-in/manifest editor.
> In CAS Viewer, each page corresponds to each CAS view (sofa). In each page
> (or CAS view), I use "sash form", "master/details block", and "sections" to
> represent/separate the logical structure of the CAS and to show the
> relationship and interaction between parts. For example, when user selects
> some "type" in the "CAS Types" section, the annotations of that selected
> type will be highlighted in the "Document" section.
> These sections are very related with each other. I don't see much benefit
> from moving from "section" to "view". If we have "multiple-view"
> (multiple-sofa) in the CAS, the situation becomes more complicated.
>

Okay, from a real-estate perspective, I guess there is not that much
difference between the two approaches.  I think the main point of
having a perspective with multiple views or editors is exactly to
support integration of different components (views and editors).  That
seems to be exactly the situation that we're in now with the CAS
Viewer and CAS Editor.  Wouldn't it be easier to mesh the different
parts of the Viewer and Editor if they were separate views/editors?

> We need to do the integration step-by-step, prioritize the works, and try to
> avoid "over-design".
>

Well, I think we're stuck at step 1, which is to decide whether to
build a monolithic editor or a collection of different editors/views.
How would you move forward without making a decision?

  -Adam

Re: Cas Viewer discussion

[Tong Fin <to...@gmail.com>]

On Fri, Aug 1, 2008 at 2:40 PM, Adam Lally <al...@alum.rpi.edu> wrote:

> On Fri, Aug 1, 2008 at 2:33 PM, Jörn Kottmann <ko...@gmail.com> wrote:
> > I still think that the huge benefit of doing it the Cas Editor way with
> > multiple views:
> >
> > + Its easier to explore a CAS file because there is more screen space to
> see
> > things.
> >
>
> I agree with that.  I've used the CAS Editor a few times, and
> basically always need to maximize that editor window in order to see
> anything.  It basically always needs to take over all of the screen
> real-estate in order to be useful to me,

"Maximize" is the shortest way to take over the whole space. If the multiple
views are used, either you "maximize" the view (which is very similar the
maximize the CAS Viewer) or "resize" the view which will affect the sizes of
other views/editors (that will take more operation to restore them back).
Basically, I don't see how "multiple views" can solve the real-estate
problem and I feel that "double-click to maximize and restore" the CAS
Viewer is still the best and the short-cut operation to switch the tasks
between viewing the CAS and do something else.

so it might as well be its
> own perspective.

Having its own perspective for the CAS Viewer won't solve the problem either
for the following reason.
If there are some files (like Java source files) opened in the editor area,
they will show up in the new perspective (we just come back to the original
issue). Most of the cases, users will have multiple files opened in the
editor area.

The approach taken by the CAS Viewer is not new. The GUI design of the CAS
Viewer is based on "multiple-page form editor" like plug-in/manifest editor.
In CAS Viewer, each page corresponds to each CAS view (sofa). In each page
(or CAS view), I use "sash form", "master/details block", and "sections" to
represent/separate the logical structure of the CAS and to show the
relationship and interaction between parts. For example, when user selects
some "type" in the "CAS Types" section, the annotations of that selected
type will be highlighted in the "Document" section.
These sections are very related with each other. I don't see much benefit
from moving from "section" to "view". If we have "multiple-view"
(multiple-sofa) in the CAS, the situation becomes more complicated.

We need to do the integration step-by-step, prioritize the works, and try to
avoid "over-design".

-- Tong

Re: Cas Viewer discussion

[Adam Lally <al...@alum.rpi.edu>]

On Fri, Aug 1, 2008 at 2:33 PM, Jörn Kottmann <ko...@gmail.com> wrote:
> I still think that the huge benefit of doing it the Cas Editor way with
> multiple views:
>
> + Its easier to explore a CAS file because there is more screen space to see
> things.
>

I agree with that.  I've used the CAS Editor a few times, and
basically always need to maximize that editor window in order to see
anything.  It basically always needs to take over all of the screen
real-estate in order to be useful to me, so it might as well be its
own perspective.
  -Adam