Feedback needed for new JauntePE 0.5.0 GUI

crownixx · **Joined:** Sat May 12, 2007 6:26 am **Posts:** 403

A small favor by Redllar requesting for ideas/ feedback on new GUI for upcoming version 0.5.0.

Originally, the request came from two separate emails. I quote the first email below, hopefully it could give you better explanation on redllar’s intention.

redllar wrote:

… a new version (0.4.0) of the main JauntePE app that's meant to consolidate all of the various tool's capabilities into one gui. Back when I designed this, I was hoping it would work well for both the novice as well as the expert JPE user. But I've since been using VirtualBox a lot lately, and I really like the way they've organized things. So I'm thinking maybe I need to switch over to a gui like theirs. In any event, the goal was to make something so appealing that you, and others like you, would prefer to use it as opposed to doing things manually. The problem I had, and still have, is how to the make it so that just a few steps are required for those like you who don't want to go through the entire install sequence, as well as make it simple enough for novice users who need to be "held by the hand." And how it should all be organized.

v0.4.0 screenshot

Download GUI
http://www.mediafire.com/?tb9x4paob9fv1fy

The email continues...

redllar wrote:

... JauntePE gui (0.4.0) is just a shell right now, so please don't bother with the details. What I'm interested in right now is your answers to the following questions:

Do you think incorporating all of the various JPE tools under one gui "umbrella" is worth pursuing, or would it be better to just leave things as is with one basic tool launcher app and all of the various tool apps as separate exes, and to spend time properly documenting each tool app?
Do you think the 3-panel layout is worth pursuing, or have you come across another style that you think would be more suitable as a gui for incorporating all of the various JPE tools under one gui "umbrella"? For instance, I'm kind of leaning towards the layout that VirtualBox uses instead of the one I came up with. The only thing I don't like about it is how each main functional area is presented as a new popup window. I'd really like to have everything contained within one main window with as few popups as possible.
Assuming the answer to question one is yes, and a really good gui design can be found and properly implemented and documented, I'd like to release the next version of JauntePE as just this one exe and without all of the current tool app exes.
- 3a) Do you think that would be a step forward or a step backward with regards to JPE's evolution?
- 3b) Do you think the separate tool app exes (and associated docs) should still be included in the next release?
- 3c) Do you think that a unifying gui app would then become the preferred method for portablizing apps via JPE, for both the novice and the expert JPE user? Or would the expert still prefer to manually tweak the settings? Basically what I'm asking here is if you think it would be advisable to rework the JPE release package so that the documentation and examples and tutorials are all geared towards starting with and using the one main app, as opposed to the jumbled and disjointed way in which they currently present things, often requiring the user to do things manually, such as what's doc'd in the "12 Steps" walk-through.

So, that's what I'm currently interested in doing with JauntePE. I want to turn it into a typical Windows app that is used to handle all of the things you can currently do with the separate tool apps, instead of the *nix-oriented toolset it currently is. I think that's what the typical Windows user would expect, would make more use of, and would greater appreciate. Do you agree? If not, please tell me why.

----------------------------------------------------------------------------
----------------------------------------------------------------------------

The second email came right after i gave my feedback on first email:

redllar wrote:

... I've attached a mockup exe of a new version (0.5.0) of the main window that's very similar to what VirtualBox uses. And I'd appreciate your thoughts on it when you have the time.

But first, it's a .Net app, so it might not run for you. The final version won't be a .Net app (hopefully.) I'm using .Net now for the mockups since it's much quicker to design the gui with, and it also has more control types available during design. Otherwise I'd have to write a bunch of code as with the 0.4.0 gui, and I don't want to do that again until we find something that looks like it's going to work well.

v0.5.0 screenshot

Download GUI
http://www.mediafire.com/?76t7xeew457rdcd

The email continues...

redllar wrote:

The main control on the right, within the Details tab area, is called a property grid. Right now it's populated with a bunch of meaningless development-time properties, but once I code it up, it'll be populated with the various JPE-related categories and settings such
as Installer, Registry Storage, File System Storage, etc., for the selected app in the left-hand list view. What's nice about a property
grid is any part of it can be made non-editable or editable, depending upon the user's preferences. So a "normal" mode of operation could be just like VirtualBox's, where only the category header label is selectable, and doing so would give you a typical settings popup box. And another "advanced" mode could allow the settings to be edited directly on grid itself, as you can do now in the mockup.

As far as all of the rest of it, I'm still undecided. I'm currently trying to come up with a list of all of JPE's tool's capabilities and settings, to see if I can find a small set of categories and sub-categories to organize them within that's more user friendly than the current set that I presented in the help docs and via JPE Builder and JPE Quickie.

For instance, for the app list view groupings, I currently have New, Installed, Portablized, Analyzed, and/or Optimized, and Packaged. So the app list groupings would represent the various stages that one could (optionally) go through to portablize an app.

And I guess the 4 tool bar buttons would be the ones most commonly used. Same with the menu items. I'm not sure about the non-Details tabs though. Honestly, I'm not quite sure how the tab bar should be used if it's not used to separate the various settings into basic categories. So the only thing I could think of was to use the tab bar as a way to should additional, non-settings-related info, such as
what you'd get from the "discovery" and "logging" JPE info.

Under the File menu, import could be a way to merge another portablized package's registry and/or file system into the currently selected one. I'm not sure what export could be used to do, so it may go away. The only "exporting" of any kind I can think of right now is the final step you can take with JPE Quickie to make a copy of the current "working" package to another drive and/or folder for actual use of the app(s) contained within.

As for the Package->New menu item, I was thinking that it could work somewhat like the way JPE Quickie works with config "templates," where you can select from a list of available package templates depending upon your needs. Some templates could be app-specific and some could be more generalized. I was really hoping that people would have made use of that feature in JPE Quickie, and to have already created a repository of sorts of such configs by now. Since that didn't happen, I would really like to make sure that users are aware
that such a feature exists in the next version, otherwise I don't see any reason to put it in again.

Again, hope everyone can join and share your opinion.

redllar wrote:

Thank you so much for slogging through all of the above. I know it's a lot to have to go through. Hopefully it's worth the read though, as I do wish to get back into JPE development.

Andrew Lee · **Joined:** Sat Feb 04, 2006 9:19 am **Posts:** 1879

I think the new GUI is definitely a step forward. I have always found the 0.4.x GUI to be a little too wordy and cluttered (partially due to the "toolbox" concept). For GUI, I am a minimalist i.e. less is more. The 0.5.x unified GUI concept is far better, IMHO. To make it less intimidating to someone starting out, it might be better to expose only the essential options by default, and include an "expert mode" checkbox that displays all available options (there will be many due to the complexity of JauntePE).

To cater to the expert users, it will be sufficient to document jauntepe.ini file in a wiki or equivalent, instead of trying to provide the tools yourself. This serves a couple of purposes. Users who like going low-level can configure the file by hand. Alternate tools can be developed that cater to users with different needs. I think both VMWare and VirtualBox has this model, and various tools and even webapps have been developed to create virtual machines without using the official GUI.

In summary, I think it is sufficient to create a unified GUI that caters to the average user. The GUI should default to novice mode, preferably with a wizard (like VirtualBox's) to guide the user through the portabalization process. But it is far more important to properly document jauntepe.ini file in a wiki, so expert users can hand-create this file, and alternate tools can be created to cater to different needs.

Quote:

* 3b) Do you think the separate tool app exes (and associated docs) should still be included in the next release?

In my opinion, no. The focus should be on the new GUI, plus a single techdoc that documents jauntepe.ini.

Quote:

* 3c) Do you think that a unifying gui app would then become the preferred method for portablizing apps via JPE, for both the novice and the expert JPE user? Or would the expert still prefer to manually tweak the settings? Basically what I'm asking here is if you think it would be advisable to rework the JPE release package so that the documentation and examples and tutorials are all geared towards starting with and using the one main app, as opposed to the jumbled and disjointed way in which they currently present things, often requiring the user to do things manually, such as what's doc'd in the "12 Steps" walk-through.

You can guess it by now, yes. Cater to the average user. Make the average case easy. Don't confuse them with too many options. Expose the kitchen sink only when asked to ("expert mode" checkbox). Expert users will find their way, so don't worry too much about them.

joby_toss · **Posted:** Sun Nov 07, 2010 7:20 am

I also like the new direction!

crownixx · **Joined:** Sat May 12, 2007 6:26 am **Posts:** 403

My response to redllar in previous email is about the same as Andrew Lee. I do agree with Andrew Lee to have more comprehensive configuration ini document. There are still lot of settings that i never play with them yet.

I had more detail response for the second email. The mind map below is the sum up of it. I'll elaborate my mind map later. Take a look if you can get the idea behind it.

-----------------------------------
As of 8 Nov 2010

In general, if we want to produce a product we must know the process flow. Yes, process flow is the critical thing we must identify first before we design/built any tools for creating a product. Baking a cake, making car, producing oil etc.. All of them require identifying the process flow first. The same case should also be applied to portablizing an application. Our product now is a portable application. Before we discuss a suitable GUI for JauntePE, allow me to make a study on the portablizing process flow.

Portablizing Process Flow
So, what is the process flow of portablizing an application?

I have been in the world of portable application for quite a time. I start with a simple batch script. Then I learn script launcher (Autoit/NSIS), commercial application virtualization and JauntePE. Based from my experience, I can “see” that all of these tools are basically using the same high level Process Flow. The high level Process Flow is

Creating a Project
Configuring a Project
Building final Package

From now onward, I will simply call the high level Process Flow above as Process 1, Process 2 and Process 3. Note that there will be two outputs from the process flow; one called Project and other called Package. I’m using two different terms to ease the documentation later. A Project is our unfinished product. It also can be said as a "source code" of the product. A Package is a finished product. I have mention earlier our product is a portable application.

1. Creating a Project

This is where the portable maker identify/collect/understand the required files & registry (component) for the target application. The script launcher & commercial application virtualization AFAIK is normally using a 2 state comparing method to achieve the goal. Exercising the application is done in the middle of the state in order to capture the entire component.

JauntePE however is using more sophisticated method. JPE Quickie redirect the installer in order to identify/collect/understand the required component of the target application. The Project is also exercising under the redirection for further step of identify/collect/understand the component of the target application.

In 0.4.0 GUI, redllar was using term Action to describe the portablizing process flow. Then he came out with Action Panel to organize the previous The 12 Step Program. The Action is probably the reason for making 0.4.0 GUI looks to wordy and cluttered. So, I would like to propose the Installing Action and Exercising/ Discovery Action to be put under the Creating a Project process flow (as shown in my Mind Map above). “Hiding” those two actions into one process flow will make it neater and we will gain opportunity to create the minimalist GUI. Note that in the Mind Map I also add Option2 as an alternative method (probably in future) for Creating a Project process. IMO, there will be high chance to integrate the Option 2 easily in the future if the JPE GUI is based on the suggested high level Process Flow.

2. Configuring a Project

For script launcher, portable maker will start preparing a script for the Product manually based on the snapshot result in Process Flow 1 and also the application behavior observation during the exercising action.

For commercial application virtualization; after completing Process 1 it will ask a user to configure the basic configuration in the wizard. Then the Product is given a specific set of configuration based on the wizard as well as snapshot result in Process Flow 1. I stated specific configuration because all application component is set to Full isolation mode by default ie equivalent to JPE [FilesystemIgnore] or [RegistryIgnore] setting. At this stage, a basic user normally accepts the suggested configuration and quickly proceeds to Process Flow 3. A Novice/Expert user however can have their time to modify/change the suggested configuration. Note that the commercial application virtualization Project file cannot be exercise further after completing Process 1 stage.

For JPE Quickie, the Product is given a generic set of configuration after Process 1, normally using _Normal3.ini. But JPE can provide a specific set of configuration (Partially optimized/fully optimized) during final build of Package based on the Discovery mode that it have. Note that JauntePE have advantage over the commercial application virtualization where its Project file can be re-exercise/re-discover back, without a need to rebuilt new Project.

As in the mind map, I put Review Discovery Result element at the top, which is equivalent to result from 2 stage analysis by commercial application virtualization & Discover usage by JauntePE. Configuration process is being split into two elements; one is Basic Configuration and the other is Advanced Configuration. A Basic Configuration consist of compulsory settings that are just enough for a basic user. Advance Configuration will be consisting of all the available settings. The “hidden” Actions behind Process 2 are Re-exercising/Re-Discovery Action and Configure Settings Action. I also add the Import Action in the Process 2 as redllar mention the about the importing feature in the mock GUI of 0.5.0. This could be a new action for JauntePE and will be discuss further later, probably in the 3-Panel GUI topic.

3. Building final Package

This is the final stage of the Process Flow. If we look at the script launcher & commercial application virtualization, they normally create 2 type of Package: a Debugging Package or End User Package. A Debugging Package is for testing purpose only and not for normal use. The End User Package is a final package that can be distributed and use normally.

Note that JauntePE’s Project file can be run without compiling it into a Package unlike script launcher & commercial application virtualization. Thus, Debugging Action is possible to be place either at Process 2 or Process 3. At this point I’m not sure which location is better so for now I just place the Debugging Action at Process 3

------------------------------------------------
Edit1: added Portablizing Process Flow>Creating a Project explanation
Edit2: update the latest JPE mind map. Added Configuring a Project & Building final Package explaination

joby_toss · **Posted:** Sun Nov 07, 2010 9:44 am

What a nice mindmap!

crownixx · **Joined:** Sat May 12, 2007 6:26 am **Posts:** 403

Updated my post above to explain small part of my Mind Map.
Comment please

. There is one issue that can bring into further discussion. As we have two method of creating a Project, in your opinion which one is the more robust method? Both method have their own advantages and disadvantages

joby_toss wrote:

What a nice mindmap!

Thank you. Looking forward for more ideas from you

crownixx · **Joined:** Sat May 12, 2007 6:26 am **Posts:** 403

Thanks for reading, though it is quite disappointed to see nobody bother giving any comment.

Below i made a proper process flow based on the mind map that i sketch before. Then i manage to explain the GUI model that could work with the process flow below. I have submitted the idea to redllar and currently waiting for his feedback

joby_toss · **Posted:** Sun Nov 14, 2010 9:43 am

Honestly, I'm overwhelmed!
I look at your mindmaps and I'm stunned! What could I say?

I don't want anyone to think that I don't care! I'm simply happy with the way JauntePE works now, I'm very pleased to see the project revived and I 100% trust Redllar's developing abilities. On the other hand, I don't use the GUI, I'm more a "12 steps" jauntizer. Give me a launcher and a .dll and I'm good to go.

webfork · **Posted:** Sun Nov 14, 2010 2:49 pm

crownixx wrote:

Thanks for reading, though it is quite disappointed to see nobody bother giving any comment.

I'm really impressed by your flowcharts, but I have very little understanding of the project you're posting about. Its always frustrating to put a lot of work into something (as you so obviously have) and not get feedback.

Andrew Lee · **Joined:** Sat Feb 04, 2006 9:19 am **Posts:** 1879

I would prefer that the "Build" step and the "Configure" step not be so distinct. And it is better if both the installer analysis and the 2-phase analysis can be included (basically JPE Quickie and JPE Setup Capture in V0.4), since the installer analysis doesn't work all the time.

Here's what I mean.

I would like to be able to create a new project and point to the target EXE. Then I am asked, what settings would I like. I can answer:

1) Target EXE is an installer. Figure it out for me.
2) Target EXE is the app EXE. Figure it out for me using two-phase.
3) Choose from one of the prebuilt settings (the old normal, normal2, normal3 etc.).

After that I enter the edit/debug cycle. Note that at any time, I can repopulate the settings using one of the methods. For example, if method 1 doesn't work for me because it's an MSI, I can try method 2. Or I think I am an expert and choose one of the prebuilt settings in method 3, but it's not working out for me, so I might want to get a little help by choosing method 2.

Then once I can satisfied, I "build" the project to produce the final portable "package".

Or put it this way. At its core, I create a new project, and there are some barebones default settings. I can invoke various modules to help me populate these settings: 1) installer analysis 2) two-phase analysis. If I am expert and gungho, I may even do it myself. Maybe it might even be possible to have a "wizard" API so that other wizards can be plugged in. But essentially, the core project IDE is like a GUI editor/compiler for jauntepe.ini. The wizards are nice-to-have pluggable extras.

Which is why I said the new V0.50 GUI mockup is much closer to what I am after. You click "New" to create a new project. The project settings appear to the right in categorized lists. The "Configure" button lets you configure the settings using one of the wizards. The "Run" button lets you debug your settings. The "Save as" button lets you save your final portable "package".

Well, maybe that's not what redllar had in mind, but that was the flow that appeared in my mind.

PS: I would like to suggest that the two-phase information be stored within the project itself so that it can survive a reboot (without having to resort to RegShot).

lyx · **Joined:** Mon Feb 15, 2010 1:23 am **Posts:** 84

Agree with andrew. After analyzation, i'd prefer to *optionally* be able to adjust settings immediatelly after capture (but please don't overwhelm me with tiny screws - first, just give me the basics (virtualized directories, files, etc), and optionally led me dig into the full arsenal via advanced options).

I really really liked the approach which thinapp did take with app virtualization. The only thing i never really liked about it's build process, was that i had to manually go to the settings file and project directory, to adjust virtualized dirs, and delete files.

IMO, it would be most comfortable, if the app were not split into multiple "tasks" like seperate applications, but instead be more like a "tree":

Go through a straight process of doing stuff, while on this main "branch", keep stuff simple (but not stupid). At any step in the process, let the user decide when he wants to get more specific about this step. So, when capturing an app, you always go through the same generic steps, and only for the steps where you need more finegrained control, you tell the app "let me adjust the fine details for this".

About the only big splitoff that imo may be needed, is to at the beginning of the process decide, if you want to capture a new application, or configure an existing one. Configuring an existing one would - after choosing a project - jump to the same steps as those that are done after capturing a project.

So, a bit like this:

0. Decision what to do: Capture application, modify existing package. Selecting capture goes to step 1. Selecting modify does - after choosing a project - jump to step 3.

1. Capture settings. Only show the basics, but give the user the option to go to a more detailed view.

2. Capture

3. Post-capture settings. Again, only provide basic most frequent options here, but offer a more detailed view.

4. Build

crownixx · **Joined:** Sat May 12, 2007 6:26 am **Posts:** 403

webfork wrote:

I'm really impressed by your flowcharts, but I have very little understanding of the project you're posting about.

Thanks. Yeah, probably you're right. My early post was too much of explaining things that were not related to GUI topic, which lead me to be in the frustrated situation to continue sharing my idea. Maybe i should just post the GUI model straight away.

Here's my GUI model idea that i submitted to redllar in case anyone interested to comment.
https://docs.google.com/document/d/1LZK ... y=CMjByOAK

crownixx · **Joined:** Sat May 12, 2007 6:26 am **Posts:** 403

Andrew Lee wrote:

I would prefer that the "Build" step and the "Configure" step not be so distinct

I'm not sure the level of distinct it could be but IMO, a separation is still required between "Build" step and "Configure" step. After the Build step finish, this is the point where a Basic User or Advanced User will go on different path of process flow selection. A Basic User normally accept the preliminary settings of the Project and straight away to proceed "Build Package" step. While an Advanced User take his time modifying the preliminary settings of the Project before he proceed to "Build Package" step.

Andrew Lee wrote:

Or put it this way. At its core, I create a new project, and there are some barebones default settings. I can invoke various modules to help me populate these settings: 1) installer analysis 2) two-phase analysis. If I am expert and gungho, I may even do it myself. Maybe it might even be possible to have a "wizard" API so that other wizards can be plugged in. But essentially, the core project IDE is like a GUI editor/compiler for jauntepe.ini. The wizards are nice-to-have pluggable extras.

lyx wrote:

Agree with andrew. After analyzation, i'd prefer to *optionally* be able to adjust settings immediatelly after capture

You know what, we have the same idea on this one. The barebones default settings was _Normal3.ini. This settings can be updated further based on the Analysis Result either from 1) installer analysis 2) two-phase analysis. Then it will also further updated based on User Input only on the basic settings. The outcome is what i called as Preliminary Settings, an initial settings suggested for a Project. The Preliminary Settings should exists first or must come first as it will mostly used for Basic User. After the Preliminary Settings exists, then we can provide an option for Advanced User to modify the Preliminary Settings.

So guys, if we can go into more details, what are the basics settings that can be combine with Analysis Result to generate the Preliminary Settings? Any ideas? For me, i would go "replicate" idea from thinapp i.e the isolation mode. This isolation mode is the same talk for redirection

lyx wrote:

0. Decision what to do: Capture application, modify existing package. Selecting capture goes to step 1. Selecting modify does - after choosing a project - jump to step 3.

1. Capture settings. Only show the basics, but give the user the option to go to a more detailed view.

2. Capture

3. Post-capture settings. Again, only provide basic most frequent options here, but offer a more detailed view.

4. Build

Your flow is fit with the process flow that i posted here. At step 0, is where you can see we have two "Start" point. It is user decision to choose "Start" for Capture application or to choose "Start" for modify existing package. Then you can go through the process as described.

Andrew Lee · **Joined:** Sat Feb 04, 2006 9:19 am **Posts:** 1879

Thanks for your GUI model document! It gives us a solid base for further discussion.

To clarify what I said in my earlier post based on your document, what I am suggesting is this:

Quote:

1. Create a Project
* Installing Action, Exercising/Discovery Action, Prelim ini Settings

I feel this "Create" step should just be prelim INI settings. Ask for the name of the target executable, choose a profile (virtualize registry? virtualize registry+filesystem? etc.), and the project is created for you.

Quote:

2. Configure a Project
* Re-exercise/Re-Discovery Action, Debugging Action, Configure ini settings Action, Import Action

As such, there is no need to "re" anything here. The exercise/discovery step goes here, along with the other options. You can hand-edit the settings if you want.

Quote:

3. Build a Package
* Package-Up Action based on user input

No problem here.

The "Install action" becomes a "Create Project From Installer" wizard. The input is the installer EXE. The output is a project. You can also have the "Create Project using Two-Phase Discovery" wizard here. Other wizards can be added when we think of them.

Why I am proposing this is because it makes simple tasks simple. Say I want to portablize VirtualDub, which comes in a ZIP file. I am not forced to take unnecessary steps. I just create the project, point to the EXE, choose a profile, and assuming I know what I am doing, I can go straight to building the portable package without configuration.

If I have something more complicated, I use the wizard to create a project from the installer. Then I get a project which I can exercise/discover/hand-edit to my liking, then build. For for me, the first priority is to make simple tasks simple.

Hope I have made myself clear, otherwise I may have to start resorting to diagrams.

crownixx · **Joined:** Sat May 12, 2007 6:26 am **Posts:** 403

Thanks for clarifying your GUI model. It can work that way too and reduce to few steps, especially for an app that is distribute in the archive (zip, 7z, rar).

Quote:

As such, there is no need to "re" anything here.

Thank you. I think you're right and it make me think to revise my current process flow..

Thanks again. Hopefully redllar got something with several ideas discussed here

Edit:
Andrew Lee, right now i'm trying to figure out how to fit your idea into my process flow if possible. Just one question. Your're idea is focusing on creating the prelim ini settings. So the application's files are already in placed before or after creating the prelim ini settings?

Feedback needed for new JauntePE 0.5.0 GUI

Who is online