CPSC 547 Project III: Webgrid

Kevin Ondic


933996


My experiences with Webgrid, at least initially, were very confusing. When constructing my own grid in part I, I found my biggest problem to be understanding the terminology, as well as finding good elements to analyze. After completing the project, it seems to me that "Classification Objects" would be a much more explanatory and intuitive term than "Elements", as would "Classification Criteria" as opposed to Property (even though property is not bad on its own). I am still not clear on why the Context and Domain/Purpose information are relevant to anything whatsoever, and how they differ from one another. However, after getting the initial "hang" of Webgrid, it became relatively straightforward to use.

In finding good elements to analyze, it took me several attempts at constructing a grid before I found some that worked well. It seems that elements which are physical and of the same class work best. For example, in classifying an animal, the constructors of swims, carnivore, and lays eggs were three of my initial elements. There are very few properties that can apply to all of these which make sense in attempting to distinguish between them. As such, I continually tried to find elements that facilitated construction of an effective repertory grid, eventually landing on such things as "mammal, bird, fish, reptile" and so on. This new found understanding of what exactly constituted potential elements made the further studies (parts II and III) much easier.

The most difficult problem I encountered in using Webgrib was that of interpretation. When asked to enter in properties to distinguish between two (or a triad) of elements, it was often difficult to do so, especially when taking into consideration that these properties are most useful if they help distinguish between all the elements being used in the current grid. When applying these properties to the other elements, it becomes clear that they can assume other meanings or different aspects of what they had originally been intended to refer to. For example, in distinguishing FTP and Gopher, a property used was "Used to Transfer Files" vs. "Used to distribute information". When applying that to the IRC, it is not really used for either function (as referred to by the ideas behind the original properties), but comes closest to "Used to distribute information", so that is where I ranked it. An example from Part II can be seen in comparing Object Oriented Systems to Virtual Reality. I used the distinction of System Design Paradigm vs. User Interface Technology. However after viewing the completed grid, it occurred to me that Object Oriented Systems can also be a model for a user interface (particularly GUI’s). As such, I believe that the results of the grid depend entirely on the frame of mind that the user is in when the grid is created; a few hours later completely different constructs and properties could be used with different interpretations and results. Perhaps one of Webgrid’s most interesting uses would be to compare one’s own perceptions at two different points in time, as opposed to comparing points of view between two different people or parties…

It seems to me that to analyze anything practical, with a relatively large scope, the time required to do this would be enormous. During the first two parts, Webgrid presented me with a seemingly endless number of similarities that it wanted to be distinguished., and these grids had relatively few elements! While the speed of the system itself was acceptable, I feel that a local desktop implementation would be required to do anything of any significant size. One small web related problem I had was that of the browser cache; instead of loading new pages, it would load previous pages (located at the same address ) which I had already filled in and/or viewed. Another system design feature that I would find handy would be a display of all pairs that the software considers to be similar instead of displaying them one at a time, linearly. If it displayed all at once, this would allow the user to pick which to distinguish from one another. This could be beneficial as some pairs are more important and useful to contrast from one another than others (some pairs may in fact be similar for a reason, and forcing the user to distinguish between them may not be the most proficient course of action!).

A ranking or criticality measure of distinguishing between similar pairs would also be useful. Instead of continuing to enter in information for a seemingly endless amount of time, the user would thus be able to stop once the systems level of accuracy had reached an acceptable level for their purpose. When I decided to quit each of the parts of the project, all of my grids still had outstanding similarities to be resolved. I was given no indication of the consequences of not continuing to distinguish these similarities from one another. Perhaps a user definable level of what constitutes similar would also prove useful.

Interpreting the graphical results (FOCUS, PRINCOM, and COMPARISON WITH ANOTHER GRID) also took some time to perform. It was not immediately obvious what these results represented or conveyed.

Part I
Saved Grid Document
Grid
PrinCom
Focus

Part II
Saved Grid Document
Grid
PrinCom
Focus
Comparison

Part III
Saved Grid Document
Grid
PrinCom
Focus

Presentation Notes