Author Topic: DcUpdater v2 Preliminary Flirtations (Read 55,158 times)

mouser · « **Reply #1 on:** March 20, 2009, 10:45 PM »

Let me explain a bit some of the motivation for the changes in the UI:

The right-hand panel is now a WebBrowser control that will allow for the display of detailed info about the selected item, including full description, screenshots, web links, other generic info.
To make room for the browser info panel i had to figure out a way to compress the wide lines of the original dcupdater, so i made each entry now have 2 lines; as a side effect this let me use larger icons.

As a comparison, here is the original v1 dcupdater:

TucknDar · « **Reply #2 on:** March 20, 2009, 10:46 PM »

Looks great, mouser! let us break it!

mouser · « **Reply #3 on:** March 20, 2009, 10:48 PM »

I should confess that i have slightly mixed feelings about losing the ultra compact small icon grid display in the old version. But i think on balance it was a tradeoff worth making. If there is real uproar i could always bring back a short 1-line per row view which hides some columns or is usable only by people with huge monitors.

mouser · « **Reply #4 on:** March 20, 2009, 10:49 PM »

I have a lot more features to add before testing.. nested groups, and a lot more behind the scenes stuff.

Darwin · « **Reply #5 on:** March 20, 2009, 10:51 PM »

Looks good. I like the two line entry in the left hand paine and the bigger icons. The web browser panel on the right will be really useful, particularly if it is able to display information about changes in the update relative to the build that is currently installed (ie version history)

mouser · « **Reply #6 on:** March 20, 2009, 10:58 PM »

Quote

The web browser panel on the right will be really useful, particularly if it is able to display information about changes in the update relative to the build that is currently installed (ie version history)

Right. With this panel we have the ability to show all kinds of information.

Deozaan · « **Reply #7 on:** March 20, 2009, 11:24 PM »

Awesome!

cranioscopical · « **Reply #8 on:** March 20, 2009, 11:51 PM »

Quote from: mouser

With this panel we have the ability to show all kinds of information.

Which will be very nice indeed... if good information is both available and updated

gexecuter · « **Reply #9 on:** March 21, 2009, 02:43 PM »

that looks sweet.

mouser · « **Reply #10 on:** March 21, 2009, 10:33 PM »

Just one sample display of some contents in the html details panel.
I'm using a template to display info, so we can easily customize the format of the info.
Note that you can click on any of those files (both remote and local) to view them.

Later we can add info for Latest Changes, author info, description, etc.

cranioscopical · « **Reply #11 on:** March 21, 2009, 11:25 PM »

That looks useful!

Deozaan · « **Reply #12 on:** March 21, 2009, 11:42 PM »

I'm excited for DcU 2.0!

ewemoa · « **Reply #13 on:** March 22, 2009, 12:13 AM »

Thanks for the sample display! I think it helps my feeble imagination.

* ewemoa hopes for checksums

mouser · « **Reply #14 on:** March 22, 2009, 12:48 AM »

does anyone have any ideas for a gui/workflow that would allow people to decide how to be handle the idea of having multiple releases of a program corresponding to stable/beta versions? how to present the info to user? how to let user say which they want to be notified about, etc.

Deozaan · « **Reply #15 on:** March 22, 2009, 01:50 AM »

Quote from: mouser on March 22, 2009, 12:48 AM

does anyone have any ideas for a gui/workflow that would allow people to decide how to be handle the idea of having multiple releases of a program corresponding to stable/beta versions? how to present the info to user? how to let user say which they want to be notified about, etc.

I think a simple checkbox in the options would be enough to allow the user to decide if they want to keep track of beta releases. Something like:

[] Let me know about beta releases. NOTE: These might be unstable and buggy.

Or it might be a good idea to allow the user to select individually (per program) whether or not to check for betas. In that case you'd need to ask somewhere else and store the choice somewhere so that it is remembered between updates That is, the .dcupdate file won't be a good place to store whether or not betas should be checked because each time you update the app it will replace the .dcupdate file.

And then perhaps the .dcupdate file will contain info about where to find betas and the server.xml file will have an xml tag to indicate stable or not. Though it would probably be better to default to stable (omitting the tag means it is stable) and only require extra stuff for betas.

Is this the kind of information you're asking about?

mouser · « **Reply #16 on:** March 22, 2009, 02:04 AM »

Quote

Is this the kind of information you're asking about?

yes. i'm trying to decide some of the issues you raised -- e.g. should it be a global setting to look for betas or a per-application setting, do i need to show people both stable version info from web AND beta info? or just one of those based on what they have asked to see, etc.

i'm not really worried about the backend issues of how to check and where to store preferences, as i am with figuring out the user interface aspects to this.

Deozaan · « **Reply #17 on:** March 22, 2009, 03:56 AM »

Quote from: mouser on March 22, 2009, 02:04 AM

Quote
Is this the kind of information you're asking about?
yes. i'm trying to decide some of the issues you raised -- e.g. should it be a global setting to look for betas or a per-application setting, do i need to show people both stable version info from web AND beta info? or just one of those based on what they have asked to see, etc.

I would definitely recommend having the option to download and install the stable version even if the user has selected to watch for betas. That way if a beta is too buggy the user will be able to revert back to a stable version.

The more I think about it, the more I think it would be nice to be able to select on a per-application basis. I don't use some applications a lot, or I may not use some of the advanced features of applications (like FARR) so a beta would not likely interest me. But there are other applications I'd love to keep watch for betas, such as DcUpdater itself, or Screenshot Captor, or Trout.

mouser · « **Reply #18 on:** March 22, 2009, 04:12 AM »

Perhaps one solution would be to implement the hierarchy of items in the display (as is already planned), and then for an application that has both a stable and beta release, these 2 releases would be shown as child items under a parent. By default only 1 child would ever be attemped to update; either the most recent one, or the most recent stable on. But user could manually choose one to update as well.

mouser · « **Reply #19 on:** March 22, 2009, 10:20 PM »

Screenshot with some grouping enabled.

The idea here is that plugins are all grouped together..
If you are watching multiple version of a program (beta vs. stable), these will also be grouped together
All other "singleton" programs are grouped under the Uncategorized section.

Note that grouping is purely optional and wouldn't be shown if you are just checking for an update to a single application.

Deozaan · « **Reply #20 on:** March 22, 2009, 10:29 PM »

Looking good!

tomos · « **Reply #21 on:** March 22, 2009, 10:34 PM »

Quote from: mouser on March 22, 2009, 10:20 PM

Screenshot with some grouping enabled.

The idea here is that plugins are all grouped together..
If you are watching multiple version of a program (beta vs. stable), these will also be grouped together
All other "singleton" programs are grouped under the Uncategorized section.

Note that grouping is purely optional and wouldn't be shown if you are just checking for an update to a single application.
(see attachment in previous post)

I don't understand that at the top level it says "Status: etc. " without saying which app it's referring to - the only reference to app is the FARR sub-item - I think you'd have to have some indication of what the other items refer to?
I havent been following the thread but maybe that's good too (as in this is my first look)

mouser · « **Reply #22 on:** March 22, 2009, 10:42 PM »

the grouping of "Status -> Application" shows you that its a hierarchical grouping, first by Status, then by Application.

so the first grouping is separating everything into 4 categories depenging on update status.
then each of those 4 categories is organized by application name.

cranioscopical · « **Reply #23 on:** March 22, 2009, 10:56 PM »

Quote from: mouser

so the first grouping is separating everything into 4 categories depenging on update status.
then each of those 4 categories is organized by application name.

Clear as mud!

mouser · « **Reply #24 on:** March 22, 2009, 11:03 PM »

Here's another grouping, this time by website where the update is located: