[wpkg-users] new web-based wpkg manager

[mscdex]

Thank you for the suggestions. Regarding the XML import/export, I'm not sure
what the purpose of this would be? The way I imagined the frontend to be was
that it would work directly with the xml files on disk and none of that
information would be stored in a database.

XSD looks like it could indeed be useful. Personally I have never used XSDs,
so I'd have to learn the format, but that shouldn't be a problem really.

Your templates idea is a good one. One of the ideas I had been thinking
about recently was the possibility of having a central repository that would
hold "packages." These would include not just the actual xml contents of the
wpkg package itself but also metadata like any sort of possible software
requirements needed by install/upgrade/remove steps (e.g. pskill, taskkill,
or any other utility) or other things they should know about the package.
Network administrators using the web interface could then pull in these
packages from the repository at the click of a button and have it inserted
into the packages directory or packages.xml file. This would save a step or
two and might make things a little more streamlined.

Ajax is something I had already planned on using. As you mentioned,
operations like re-ordering priorities of packages, checks, and other things
would greatly benefit from functionality like this and allow the opportunity
to be much more efficient.

As far as usability is concerned, I'm thinking about using an MVC framework
ala CakePHP. This way, if for some reason the default view does not "work" a
user generated template can be used instead. Although I will aim to create a
useful default interface from the get-go, I think having that option on the
table might be appealing to some?


Brian

On 8/3/08, Rainer Meier <r.meier at wpkg.org> wrote:
>
> Hi,
>
> mscdex wrote:
>
>> Lately I've been tinkering with the idea of creating a new web-based
>> utility to manage wpkg profiles, packages, etc. The existing wpkg web
>> utility is outdated (last updated in mid-2007ish) and the maintainer for it
>> appears to be no longer active. I believe having a decent (and active)
>> frontend project would help a lot of people, even those of us who don't mind
>> manually modifying XML files and such. It might even allow many of us to
>> "sell" wpkg to some of our clients by showing them how easy it is to manage
>> software deployment (for free!)
>>
>
> I absolutely agree. Personally I am still using WPKG WEB even if it is
> unmaintained and I cannot use some features introduced by myself into WPKG
> ;-)
> In fact I could export the XML files at any time and continue to use XML
> files. I don't mind editing XML files but WPKG WEB provides a more nice
> interface and it is good if some GUI is available to show to some
> administrators looking for a software deployment tool like WPKG. So I really
> support the idea to develop a new web-based package management tool.
>
> So now let's list some suggestions:
> - XML import/export
> I think it is important to support exporting the resulting XML files. This
> helps for debugging or in case somebody will switch from GUI to manual XML
> edit.
> The import feature seems to be very important to me in order to support
> smooth migration. Probably it does not make much sense to migrate the
> current WPKG WEB database but just export all XML files from WPKG WEB and
> then import the XML files to the new GUI.
>
> - Support XSD
> I worked on some XSD files to define the syntax of package and other WPKG
> XML files. By loading the XSD file within the GUI it should be possible to
> provide an editor which displays a nice GUI with pull-down lists for
> enumerated lists, check field contents by XSD definition and so on. I am
> also thinking about a kind of "advanced" button on the package edit page
> which would allow to insert/edit all attributes according to XSD (in case
> the GUI does display only the most frequently used ones). This would allow
> to support new syntax, attributes and nodes even if they did not exist when
> the GUI was created.
> There might be a "plain-XML" tab/button as well to allow direct edit of the
> XML source (which is of course validated by XSD). This could even convince
> hard-core XML administrators to use the GUI as it offers full flexibility to
> them.
>
> - Templates
> Most packages are based on a small number of installers. For example NSIS,
> MSI and InnoSetup are very common. It would be nice if there would be some
> (customizable and extensible) templates available to the administrator. So
> one could click on "create new NSIS package" and a new package which already
> includes "%SOFTWARE\softXY\setup.exe /S" as the installer command and the
> likely.
>
> - Ajax
> Well, nice buzzword. I hate buzzwords. But in this case I see some very
> nice use cases. The current WPKG web interface for example allows to
> re-order checks or commands. However continously clicking on the "^" or "v"
> button to move an item up or down is annoying. The same applies for
> different sections of the XML files. I like the tabbed interface of WPKG WEB
> but it needs to reload the whole page on each operation.
> Well, this is not a blocker but could for sure increase speed and
> usability.
>
> - Usability in general
> Unfortunately this is nothing which can be described in general. I think it
> needs to be a process of discussion. Especially developers tend to create
> huge, complicated GUIs which provide very poor usability. I am sure we have
> some people on the list which could then contribute to make the GUI better.
> I just suggest to be open to usability comments or even better: ASK FOR
> USABILITY COMMENTS.
> In general I suggest keeping the main GUI slim and easy to use with some
> extension points (like "advanced" or ">" buttons to open an advanced edit
> panel or similar stuff). I would say 90% of the packages can be done with
> very few configuration and 80% of the WPKG features are only used in very
> very rare cases. Try to follow the KISS principle (Keep It Simple and
> Stupid).
>
>
> Just my five cents for now,
> Rainer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20080803/430f2182/attachment-0002.html>