Jen, You mention hating to create a UI based upon the internal representation. I'd like to respectfully disagree.
When you say internal representation I think of DOM or JDOM. It seems to me that you are instead referring to the characteristics of the DLM model. Given that DLM's locks are based on containers that can have attributes and contained objects, and given the associated locks that can go with those containers(can delete, can move, can add child, can edit attributes), is seems logical to me to design a UI that relies upon those characteristics. The only reason that it wouldn't is if you want that UI to work with other layout management schemes like ALM and SLM. That in my view is the wrong way to go. If we require UI capabilities to support multiple layout management implementations then any UI that we create must be relegated to using the least common denominator of functionality between the layout management schemes that it purports to support. I recommend choosing which layout management scheme your feature is built for and then leverage the characteristics as much as possible to enhance the goals of your UI. For example, look for and use the dlm:xxx attributes as needed but make it clear which layout management scheme is required for your features. This is, in a related way, why I added the processing pipeline to begin with. The structure and theme are pluggable in nature and hence the portal may not be rendering as tabs, columns, and channels. The pipeline allows us to take that into account and plug whatever processors are needed for a specific structure and theme in use. Hence, the structure, theme, and URL handling pieces specific to those can all be packaged as a unit and plugged in via configuration for a site. It would be nice to be able to support multiple pipeline configurations so that multiple structures and themes can be used simultaneously. But the pipeline doesn't do that yet. But it would not be a hard enhancement. I just didn't get time. So if you, and others, agree with my thoughts then lets look more at the specifics and decide how the UI should logically behave given the different combinations of locks placed on the items. But first lets decide if we agree or not so that we know how to proceed. Thoughts? Mark On 7/11/07, Jason Shao <[EMAIL PROTECTED]> wrote: > > On Jul 11, 2007, at 11:17 AM, Jennifer Bourey wrote: > > > In particular, the UI we created for column editing presents conflicts > with DLM's internals that don't seem easy to reconcile. To simplify the > interface for our users, we changed from a model where users create and > remove individual columns to one where users simply choose between one and > some fixed number of columns. When columns are eliminated, the contained > channels are appended to the new last column, rather than deleted from the > layout. In our user testing, this seemed to eliminate confusion. > > This works great at Yale, where we never lock columns. However, what do > we do when DLM restrictions for columns have been set? The ajax UI > currently does the following: > > 1. When the user decreases the number of columns, delete columns as needed > from the right-hand side, and append all contained columns to the end of the > last preserved column. > 2. When the user increases the number of columns, append columns as > necessary to the right-hand side. > > I can envision a number of potential conflicts between this model and that > of DLM: > > 1. User tries to change from two columns to one column. The second > column is deleteable, but the first column is locked down such that the user > can't add new channels. The AJAX UI would try to delete the second column > and move all the channels to the first column (which isn't allowed). > 2. User tries to change from two columns to one column. The second > column is not deletable, but the first column is. In this case, the AJAX UI > would try to delete the second column and fail, although if it tried to > delete the first instead, it could decrease the column count to one, as the > user requested. > > I hate to design a user interface based on the internal layout > representation of the java code, but I'm not sure how to sort out the > conflicts between these two models. What do we want to do? > > > I wonder if we can design a quick heuristic to enable/disable the column > switching based upon the restrictions. > > e.g. > - no restrictions - current behavior > - locked tab - disable column changes > - column restrictions (anyone using these?) - allow additions, only allow > reduction in columns if there's at least 2 unlocked columns. > > Of course, if the say rightmost column was the locked one this might be a > little confusing. I'm not sure if some kind of translucent highlighting > while column changing is selected to give visual cues might help address > this -- maybe a lock icon and overlay over locked columns? > > Jason > > -- > > Jason Shao > Application Developer > Rutgers University, Office of Instructional & Research Technology > v. 732-445-8726 | f. 732-445-5539 | [EMAIL PROTECTED] | > http://jay.shao.org > > > > -- > You are currently subscribed to [email protected] as: > %%emailaddr%% > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/uportal-dev > -- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/uportal-dev
