[wpkg-users] WPKG Client 1.3.4 released (testing release), including 64 bit support

[Rainer Meier]

Hi Tomasz,

Tomasz Chmielewski wrote:
>> For that I created some easy-to-parse printouts. So actually I think 
>> the GUI should be responsible to display localized information to the 
>> user - just receiving technical data from wpkg.js.
> 
> I beg to differ here.
> The main reason is that wpkg.js is an interpreted, human-readable 
> language, and thus, can be easily changed by virtually every admin.
> WPKG Client, on the other hand, is a binary, and virtually no one can 
> change the way it interprets the data in gets from wpkg.js, unless 
> someone modifies a source of a complicated language (when compared to 
> JScript), compiles it from scratch, and redistributes to dozens of 
> workstations.

The fact that wpkg.js is a human-readable script does not change 
decisions regarding the architecture of the platform. There is no reason 
why WPKG client could not use localization (lots of open source projects 
support multiple-languages by localization files).

But the main issue which was not taken into consideration is that WPKG 
client needs to parse the information forwarded by wpkg.js in order to 
display some output on the GUI. Of course wpkg.js could forward the 
messages exactly the same way as they should be displayed. However that 
is only the easiest possible solution.

I had a much more advanced interface in mind where WPKG client parses 
the output of wpkg.js and displays some much more nice figures 
(diagrams, progress bars etc.).

This is only possible if WPKG client can easily parse the output of 
wpkg.js. This is exactly the reason why I push to clearly split up 
components using the MVC pattern. The sendStatus interface is a clear 
data interface between two components. It is not a GUI interface where 
wpkg.js displays messages to the end user. It is just forwarding data.

If wpkg.js would translate the messages (for example by defining 
messages within config.xml) then it makes it almost impossible for WPKG 
client to parse this printouts since they might look different on each 
installation. In particular some of the fields presented to WPKG client 
currently might be omitted then since somebody does not like to see the 
progress "(1/14)" on the end user screen.


> But first, before we argument some more, we have to define what data we 
> would like to display in a logon/shutdown delay window. First, let's 
> take a look at wpkg.js /sendStatus output:
> 
> 2008-05-16 12:49:02, STATUS  : Starting software synchronization
> 2008-05-16 12:49:02, STATUS  : Number of packages to be removed: 0
> 2008-05-16 12:49:02, STATUS  : Install: Verifying package 'KB888111' (1/14)
> 2008-05-16 12:49:02, STATUS  : Install: Verifying package 'Mozilla 
> Firefox 2.0' (2/14)
> 
> 
> And here are some of ideas for the logon/shutdown delay window, we have 
> some of them already:
> 
> 1. Obviously, we need some messages that change every few seconds (these 
> two defined in wpkginst.exe) - it signals the user that everything is fine.

Something like this - or another moving element could be helpful. Like 
such a popular turning circle animation (vista hourglass replacement or 
Firefox loading indication).

Personally I don't see the reason why we should still use two 
alternating messages. It could also be one single message and having 
another element on the GUI showing/faking some activity (in addition to 
the progress bar which could freeze for some time).

Earlier I also suggested some kind of Statistics. From the data 
transmitted by the sendStatus function the following fields on the GUI 
could be displayed (below progress bar probably):

- Deployment started at           : <date when synchronization started>
- Total run time                  : <current time - start time>
- Current package install duration: <current time - install start time>

The time values could be updated each second which also shows some 
progress to the user.


> 2. Because some users don't read messages displayed by a computer, 
> something "that moves" on a screen is needed. Currently, we have a 
> "pseudo progress bar".

Well right - see above for some more ideas.


> 3. What about a real progress bar? After all, at the wpkg.js outputs its 
> progress, by using (1/14), (2/14) and so on. To be frank, I'm not very 
> sure about this. In certain scenarios (a classroom full of workstations 
> connected over wireless, installing something heavy, like Office). As 
> wireless + many workstations = slow, it will mean the progress bar will 
> halt for several minutes. Users, room cleaners etc. other non-technical 
> people are very often friendly people, and sometimes they just "hey, the 
> progress bar hanged on some of the machines, so I just restarted them, 
> you don't have to thank me!".
> So what about displaying a percentage, in numbers (7%, 58% etc., 
> calculated basing on (1/14), (2/14)...) in a "pseudo progress bar"?

Well a progress-bar implicitly indicates some percentage. WPKG client 
could calculate this from the sendStatus output (as suggested). However 
displaying some absolute numbers might give additional information to 
the user.



> 4. /sendStatus displays things like "Install:" etc. - I don't see why it 
> can't be delivered in a proper form by wpkg.js (changeable in 
> config.xml). After all, WPKG Client interacts with only one program 
> (wpkg.js), an there are no plans to change it.

What do you mean by "proper form". In fact the intention was to provide 
a format which contains all data in easy readable format 
(machine-readable). This offers maximum flexibility to (various) GUI 
implementations to display as much information as intended by the 
administrator.
Again, if wpkg.js displays some nicely formated and localized strings 
here, then WPKG client will not be able to parse them properly. So a 
progress bar will be very hardly possible.

In fact I also thought about extending the package format to include 
some package description (which can be provided in various local 
languages). Then it would be possible to print this information to 
sendStatus output as well. So WPKG client could display some nice 
information about the application currently being installed/upgraded.


Let's outline the GUI as I see it:
________________________________________________________________________
| WPKG package deployment                                              |
|                                                                      |
| Deployment started at: xx:yy:zz                          [ACTIVITY]  |
| Running since        :    yy:zz                          [INDICATOR] |
|                                                                      |
| Stage: [Remove|Install]                                              |
| Package 2 of 10: Adobe Acrobat Reader                                |
|  __________________________________________________________________  |
| |-----|                                                            | |
|  ------------------------------------------------------------------  |
| Package status:                                                      |
| Installation started at: xx:yy:zz                                    |
| Running since          :    yy:zz                                    |
| Description:                                                         |
|  __________________________________________________________________  |
| | Adobe Acrobat reader                                           |^| |
| | Acrobat reader is used to display PDF files.                   | | |
| | [some more information about the reader]                       | | |
| |                                                                |v| |
|  ------------------------------------------------------------------  |
|______________________________________________________________________|


 From my point of view such a windows would provide quite a fair amount 
of information to the (waiting) user.


br,
Rainer