-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Wednesday 21 January 2004 7:57 am, Andras Mantia wrote:

I'm cool with it. I think one needs to be overly idealistic to start a project like this so I consider my neurosis healthy here. ;-)

Certainly that makes sense for being able to polish up some things. We haven' heard from Nicolas here. I would like to see what mood he is in at this point in his trial by fire. ;-) That will help me to know what I need to advance in my PR for him.

Actually I'm laughing. Just one? You're not talking about object syntax either are you? ;-) Care to offer some wild speculation on achieving the parser nirvana we've been expecting for 3.2 so that David can finish his Javascript work? Because that would really be a feather in our cap and a critical piece of infrastructure to advancing Quanta support.

Also we were exploring being able to use modular plugins in the parser so that languages or aspects could be optimized and hard coded. Somehow I doubt we can do a lot here in a short time.

I can't tell you how much I want them.

Which one?

Fine.

Currently actions can be "triggered" by buttons, keys and template insertion. Sorry, it was late. All I mean is that we need to be able to initiate actions other ways so that the automation process is more under user control for application design. For instance... I'm designing a documentation project for my company and I want to insure some things are done when files are saved or whatever... I set the project up so that the person using it can't possibly mess up by automating some behavior with scripting. This is the logical way to do this and this means that we can make quanta more suitable for content management by advancing the "personality and automation" within projects.

We could set up a project load and unload script to rewrite xmlgui so that the interface was simplified for content management. If we set the mechanism up Quanta could detect that it was being opened with required project unload modifications not called and restore the environment.

I realized that as I was typing it. My only concern was if a large amount of this data with DTEP groups might have any affect o performance?

Thanks. I was thinking how to flesh out toolbars after a DTD import without the tedious task of going to design mode and this enables design to coincide with work which is always preferable. It is my "lazy automation assist" concept. ;-)

Auto completion offers tags based on the relationship. We should be explore disabling tags on the toolbar that are not in the relationship. In fact this was a preferred solution to make VPL a lot easier to implement for Nicolas. Currently the toolbars are very un-intuitive in this regard and the auto complete functionality is unavailable to VPL. Catch 22.

Think of it as personalities. The idea is that Quanta could interpret some aspects of what I am doing and offer toolbar presentations based on that. How to best go about it is not totally clear. Initially I had thought to have Quanta offer the relevent toolbar so the user didn't have to select it, but this is not completely effective it you think about it. Another possibility is to construct a toolbar on the fly from relevent tags... intriguing but probably not very fast or fluid. The advantage to the toolbars we have is that you know where the icons are. The disadvantage is you could end up switching between 3-4 of them building a formatted data form, which is not intuitive.

In balancing these several concepts seem to offer counterpoints. familiar layout <-> specifically applicable actions pre-made toolbars <-> dynamicly created toolbars feature oriented toolbars <-> task oriented toolbars

Currently Quanta is solidly to the left and only to the left on all three of these points. I began considering adding task oriented toolbars. Which is better? If you could be certain that the toolbar would do the following you would have perfection: 1) orient correctly to every task 2) retain familiarity of layout for variations and segue to next task 3) offer only proper tag relationships

Inherently some tasks cannot be discerned from context but could be defined by the user. Selecting a task modality could convert all toolbars to the applicable tagging, not just one. However you may want to be in a standard layout in one situation (certainly in a blank page) but assume modal personalities in others (common data design scenarios).

So we can say this about the ultimate solution: 1) I don't think anybody is really anal enough to already be doing it. 2) If it could be accomplished it would be very very cool and get a lot of press. 3) It cannot be a single solution, thus it's multiple "personalities" 4) Basic structure and layout will take experimentation, and user feedback. In fact it would take a fair amount of study and refinement. 5) No single solution is possible so it must allow for easy user extensibility

Because we hope to be able to make VPL play a larger role we cannot discount the importance of good toolbar layout. Making toolbars load with a DTEP is a good start as are user toolbars. Extending intelligent context sensitive task extentions will make a big difference, especially when dealing with the huge diversity of tasks and preponderance of tags out there.

My vision is not just someone saving a toolbar for a task, but saving a whole personality. Imagine these as dowloadable resources. ;-)

We also need linked templates to work. Right now they work local, but when you upload things break. Any linked template needs to be copied and links manipulated so that they don't break on line.

Eric

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFADuu+SiV5TqRTAEsRAkQVAJ0U83cOPNSv3mA9J6l4V9LoH5VWFACfWC24 GP5iVFWqhksu3Hi1ykWGbj8= =GS+l -----END PGP SIGNATURE-----