ViXEn: The Visual XUL EnvironmentThursday September 7th, 2000From the mozilla.org website: "Vixen is designed to be a Visual XUL IDE similar to Visual Basic, Delphi, Macromedia Dreamweaver and Glade, but for the XPToolkit technology developed by the Mozilla project. The initial goal of Vixen is to allow developers to quickly develop professional quality dialogs and windows without having to write any (or at least much) XUL or CSS by hand. The long term goal is to create a comprehensive development environment for rapid development of XUL applications." What are you doing? Pet projects contribute to the stagnation of Mozilla. Joseph Elwell. i would IMMEDIATELY change the name, if you don't want others to laugh their asses off on it... Right. I mean, ViXEn sounds like it has something to do with Vi, the most ridiculous editor in existence. Nobody will be able to take this project seriously until the name is changed to avoid associations with that program. ;) ... would be to work on getting Ender to reliably and effectively edit XUL documents. Second would be a visual CSS editor that lets you edit stylesheets - and by extension, skins. Both of these, but especially the second, would be extremely useful outside the context of ViXEn. In addition, they would be at least the two single biggest tasks in any such project. I'd suggest tackling these first... If you read the web page, it relies on some of Ender's functionality (undo/redo). I'm sure it will integrate further. Do you have any ideas? Well, my thought was to simply extend Ender rather than reuse parts of its functionality. Ender is already modifying DOM trees under the hood, and I can't believe it makes *that* much difference whether the DOM trees in question are XML or XUL or HTML. You would need a different set of editing rules and some new toolbars with the XUL elements available rather than the HTML ones, but that sounds like it would be about all that was needed. Sounds easier than writing a XUL editor from scratch, even if you do borrow the undo/redo. However, all I know about ender is from reading the newsgroups, and I haven't even been subscribed to .editor for some time now (reading every mozilla newsgroup I was interested in was just taking too much time). So I don't really know how feasible this is. Just throwing it out there as a suggestion that *seems* obvious, to see whether it really is feasible. Vixen sounds like "wichsen" in German - and that is the word for having sex with yourself. So If I should convince my boss to use your tool, PLEASE get a new name for it ;) I read the requirements page and saw nothing that would indicate that an actual user experfience design process is being applied. there's not a word about who the users are, what tasks they want to perform, what environment they will be working in, what their workflow for their tasks is or will be, what the end result they want out of their tasks will be, and so on. Needless to say, at least for anyone with a ue design background, all these questions are critical for good design decisions to be made. The idea that you'd be placing widgets and windows before having a well-developed idea of users, tasks and environments is beyond retro, and this approach can only result in software that is useless or highly problematic under real-world conditions. yeah, and what were they thinking when they invented that damn wheel contraption.... They should have been focused on the bucket seats and the automatic transmission. This project is merely in the ideas stage at the moment. The first goal is a tool that allows engineers to put together dialogs based on solid UE specs in a short timeframe, using the correct shared styles and whatnot. The reason Mozilla is so pitiful from a polish perspective is that many dialogs are not utilising the code in communicator. Even a simple visual tool (like the MSVC dialog editor) would help a great deal. That does clarify the user requirements significantly. I wonder why it would be too difficult to put in a few paragraphs explaining this in the requirements. I think you have given a mistaken impression that the tool is for the use of user interface designers building general-purpose application code, not Mozilla engineers implementing specs from UE designers. |