Winbuilder - Is It User Friendly?

I should perhaps clarify that this post is more about the winbuilder projects than winbuilder itself.

The comments in this post are entirely my own opinion. Please bear in mind that I am speaking from my own perspective as a winbuilder noobie.

I read with great interest this thread by MedEvil - Little Rant.

When we started out or at least when i joined, the goal was to build a better PE and have our projects be easier to use.

I think we acomplished the first .....But with the second we failed miserably.

For the record, my intention here is not to upet anyone. I just want to...

Participate: You don't need to be an expert, write your opinions and learn

As an outsider I can honestly say that the Winbuilder projects would (IMO) benefit far more people if some of the points raised in the Little Rant thread were addressed. I'm not going to mention any particular projects - I have attempted to use several.

Nuno Brito stated (here) -

If Hiren is popular, is because people nowadays still don't see the current building processes available as intuitive or simple that can be done in two or three clicks without fuss. This means that our own works need to be made simpler, and not just "elite".

Nuno really hits the nail on the head. Excuse the profanity however people (myself included) can be lazy b@stards. Time is precious to me right now and the Winbuilder projects I have experimented with are not user friendly enough for my needs. I feel that they have perhaps become elite or require too much specialist knowledge to get them working. Something with such a steep learning curve is going to put off a lot of people - some of whom may never return.

After successfully building a working XP based project (after several attempts that didn't work) I made a backup of the resulting ISO and have since scripted various batch files that allow me to mount and edit it. This took hours, but for me was preferable to having to use Winbuilder again.

This is not an attack on winbuilder but is a reflection on how complicated projects can become. I personally think that some projects try to achieve too much in terms of covering all bases. This just adds to the amount of user defined options and further moves away from the winbuilder process being intuitive or simple.

Please bear in mind also that I'm well experienced with building and using Windows PE and have an above average understanding of Windows PE. If I'm struggling to get things working with my experience than how do you think newcomers will feel?

Regards,

Misty

p.s. Let the flaming begin

I don't think there will be some actual flaiming (or not much).
The main people involved in the raised issues are AFAIK still in "shock and denial" mode.
They will have to go through "pain and guilt" before being able to reach "anger and bargaining" .


Wonko

@wonko
I'm about to log off for a while as my account restrictions mean I only have a maximum of 4 more posts (after this one). It's a shame as I was hoping to knock you off of the number 1 spot in Today's Top 20 Posters.

You made some very interesting points about using existing community resources in the Little Rant thread (here).

@everyone
At what point does backward compatibility become self defeating? Is it time to make a clean break?

I have work to do at home and will look forward to checking back in. I'm in danger of being stuck in front of the PC all day and not getting anything done.

Regards,

Misty

I have work to do at home and will look forward to checking back in. I'm in danger of being stuck in front of the PC all day and not getting anything done.

Lolcat says:





Wonko

Ive been trying to build a successful pxe livexp boot disc for weeks. I got win7 working after a LOT of research, arguing, and building. I found building on my work computer with the exact same scripts would give me different results across different computers which was also frustrating since I like to bring my work home with me some days.

I am pretty flabbergasted that there isn't a default template that just works. If I could just start from something that works and then slowly ween down the file size by removing items to see what happens as I go then my projects would be a lot less frustrating. If there were other alternatives that aren't ancient like bartpe I'd be gone already to another project but this is what we have for now so try to make the best of it I guess.

When one compares the early projects and the recent ones, one notices that the main difference (aside from newer Windows versions being used) is featuritis. The same desease that plagues Linux software.

Instead of giving people, what they actually need, they get all the features and options possible.

Imo, we have reached, already some time ago, a level of granulate in our projects that's only self serving.

It's the software equivalent of spezial collectors items, like a watch for more than 20000$ or a pocket knife for more than 1000$.

Yes, there are some crazy people out there, who look exactly for that, but most people don't care for 'extra value' which has no bearing on real world application.

When one compares the early projects and the recent ones, one notices that the main difference (aside from newer Windows versions being used) is featuritis. The same desease that plagues Linux software.

Instead of giving people, what they actually need, they get all the features and options possible.

One of the recent projects is multiPE. Please check it against your statement:

• In the download page you can read that full 64 bit support is not intended. (A rescue PE does not need to use more than 4 GB)
• All multimedia features are missing (When repairing a system, I do not want to hear my favoured MP3s)
  Exception: Sound support for NVDA. Blind people using NVDA need the sound)
• The XP track does not try to use WIMs (WIM is not native for XP)
• ...

Peter

And your project is not different, despite of what you think.

Yes, you give the people 'less of a PE' than most other projects, but that's not, what i've meant, by featuritis.

You give less features in the build PE. That's not more userfriendly, it's less.
I actually don't see multiPE any different than nativeEX. A nice base for a project, but not as a usable project by itself.

I was talking about featuritis in the projects themselfs. There are tons of options in addition to a high number of scripts. Who needs so much choice to build a working PE? Nobody. That's who!

We just have some geeks / nerds / collectors, which want as much options as possible, to get the bragging rights that come with having the smallest / the biggest / the fastest / the ... PE.

Who needs so much choice to build a working PE?

Thats the thing. The more options the better.
By default the regular user should be able to use the defaults to create a minimal pe with not alot of wistles and bells.
Then you have others who want more options, depending on their PE's goal.
Simple, middle,or full blown. Ive build different pe's for different situations. Rescue, media focused, and some more non traditional ones.

@everyone
I did not start this thread with the intention of a discussion on the merits of individual projects. Despite not having used them all, I will continue to believe that all of the projects have something to offer.

I was a long time user of BartPE until Microsoft made WinPE 2.0 available to the public. I recently required however a PE 1.x build and gave Winbuilder a go. Having successfully created (after much trial, error and frustration) some winbuilder PE 1.x projects/builds I can in all honesty say that the actual working PE was far superior to my previous BartPE builds. The base PE was not only smaller, but had more functionality. A remarkable achievement and a testamant to the skills and knowledge of you good people here at reboot.

In my current day job, (some of) the buzz terms at the moment include "Customer Journey" and "User Experience". bradgillap, in post number 5. states -

I am pretty flabbergasted that there isn't a default template that just works. If I could just start from something that works and then slowly ween down the file size by removing items to see what happens as I go then my projects would be a lot less frustrating....

Not a great user experience. Neither is my own. This is the kind of honest comment that I was looking for when I started this thread. If you want more satisfied customers then please consider our experiences. If you are maintaining these projects for your own personal needs and/or they are aimed at the elite, then that is fine - just be honest about it please.

Please refrain from project comparisions. I don't want to start any arguments about this. I am far more interested in Customer Journey and User Experience examples. If we get enough of them then someone will hopefully start to consider our needs.

Regards,

Misty

@Misty
I am pretty sure that the mentioned projects were cited only to give some examples of the "wrong" base paradigm used.
So I will cite another one!

For a number of reasons, already talked about to death, the only projects that I feel confident suggesting to a newcomer are Amalux's "frozen builds" (and yes, as often happens he is nonetheless affected by a - light - form of featuritis).

Going outside the Winbuilder world, one of the most UNfriendly programs ever conceived by a programmer is nlite .
Notwithstanding the very good work nuhi made, the program presents you with a zillion of options WITHOUT providing any relevant info about the connections and dependencies that a choice (ticked for removal or unticked) will cause to the result.

The Winbuilder usage paradigm is very similar (independently from the project).

You choose an option and this option has one or more dependencies or conflicts (but you are not told about it) in another level or in something titled in a completely different way, so that no new user can be able to guess that if he ticks "x" he also needs to untick "y" and to add in "z" a path to a file or directory.

Let's take a look at a completely different philosophy of user interaction, an installer.
The user is presented in sequence a number of questions that he has to answer and - depending on the answer given the next "panel" is displayed, but - on advanced installers, the next panel is conditionally chosen depending on preceding answer given.
I.e. the user is guided along one of several available paths but each path leads to a working build.

Maybe is this kind of "helper" that is missing?
Or another possible approach could be giving to each project a set of "pre-set" choices i.e. "blocks of settings" already verified and tested.

There is also a psychological effect, if the new user at first try is able to creeate a working "basic" build, it is likely that he/she will like the expereince and do it again and again, adding and removing things and getting experience.
If the first successful build only happens after several failed attempts, a few BSOD's, etc. a large number of users will simply dump the whole thing and never try again.



Wonko

You choose an option and this option has one or more dependencies or conflicts (but you are not told about it) in another level or in something titled in a completely different way, so that no new user can be able to guess that if he ticks "x" he also needs to untick "y" and to add in "z" a path to a file or directory.

This is sadly an amazing description of my experience(s) - Wonko, you are a mind reader.

Let's take a look at a completely different philosophy of user interaction, an installer.
The user is presented in sequence a number of questions that he has to answer and - depending on the answer given the next "panel" is displayed, but - on advanced installers, the next panel is conditionally chosen depending on preceding answer given.

A very good suggestion that would IMHO be welcomed by many.

Here is my novel idea for a Winbuilder WinPE 1.x (XP/2003 source) project.

1 - Enter path to source files

2 - Hit a nice, big (hard to miss) BUILD button - this will create a minimal set of (working) base files. This will include the shell of the project creators choice. If the project creator wants to let the end user select an alternative shell, then another base script could be offered. This would only add one additional step/option to the initial process.

3 - Have a post processing option that will copy the base files created in step 2 to a temporary location - avoiding the need to rebuild the base every time the end user wants to add something to their own build.

NOTE - All additional steps will use the files created from running step 3 as target.

4 - Have a post processing option to add applications (possibly including drivers - or add a seperate step for driver integration).

5 - Have a post processing option to select the environment it will boot from. E.g. Standard CD/DVD build with Ramdisk; Standard CD/DVD build with FBWF (File Based Write Filter); Ramdisk based - and please don't call it bootSDI. Ramdisk can be subdivided into suboptions if required for firadisk, winvblock. w2k3 files, etc. Only one of these options can be selected. To include a description of each - including pros and cons.

6 - Another nice (BIG) BUILD button to create an ISO file.

Provide clear instruction for how the end user can test the output file in a VM if they require this option. Even list a selection of VM's and where to get them.

Provide clear instruction for how the end user can do some of the bloody work themselves - e.g. If you want to run this from a USB disk, extract these files from the ISO, and......................

There are far too many variables to cover every conceivable option that every end user might want. Why try - it's just adding a layer of complexity to the projects.

My apologies if this already exists. I'm not familiar with all Winbuilder projects.

Regards,

Misty

Please note - this is based on how Microsoft offer WinPE 2.*/3.*. Step 1 and 2 are skipped and replaced by installing the WAIK. WinPE 2.*/3.* includes the base build in boot.wim - everything else is post processing.

With a high degree of agreement you describe the idea behind multiPE!

Peter

With a high degree of agreement you describe the idea behind multiPE!

I guess that we could make a site with just Amalux's "frozen builds", MultiPE (and wimb's builders/thingies ) and close the board.

They are all excellent projects/thingies , but it is NOT what we are talking about, we are talking of "generic" usage paradigm of Winbuider.

There is no doubt that there always be some "more newcomer friendly" projects, some "more feature filled" ones, some "better programmed/made" ones, but an user should be able to use nonetheless each one in a similar mannner, or - if you prefer the point here is to try and find a way to make the intial learning curve less steep then it is now.

As said in the referenced thread, there is nothing particularly "bad" in the usage paradigm if not the fact that the Winbuilder is falsely presented to the user as a "simple, easy to use" app (while it's usage is very complex), the attempt is to try and find ways to have the declared easyness of use a rightful and correct statement.


Wonko

Thats the thing. The more options the better.

That's exactly the point that i argue.
There is for instance the rule of the 7.
If one gives people only 1 item to choose from, they are unhappy because they have no choice. If you give them 20 irems to choose from, they get frustrated because they can't fathom 20 items all at once. It becomes a strain to pick the best choice.
The number of items, that makes people the happiest, was found to be 7 items.
It's the max number of items people can keep all at once 'in memory'.

Besides, only zen masters care about the way to the goal, the rest of us just cares about the goal itself.

- I want a small CMD PE.
- I want a small Explorer shell PE.
- I want a Full blown PE with everything.

Top that with some options to customize the GUI and one will have a whole bunch of happy costumers.


Have a look at our two favorite projects LiveXP and Win7RescuePE. They are by no means the best projects, but their names are the best.
Every newbie that wants as much features as possible goes for LiveXP. Because it can only be a XP that works Live from CDVD. Not like the rest a mere PE!

Win7RescuePE, same story. I need to rescue my windows7, what project do i use?


And as far as script interfaces go. The biggest problem is the overuse of checkboxes. They do not only clutter the interface, but not seldom allow for combinations, that make no sense. A good user interface 'frees' the user from thinking. Combinations that make no sense, are usually not possible.

Since Winbuilder has not the ability to grey out or set certain option depending on others, the only way to a user friendly interface, imo, are scrollboxes with presets of useful option combinations.

Here's how I set my options in scripts depending on settings in other scripts.

// CHECK IF ANYAPP.SCRIPT IS SELECTED, IF CHECKBOX1 IS SELECTED THEN SET INTERFACE ACCORDINGLY //
If,ExistFile,%ProjectDir%AppsAnyAppApp.script,Begin
IniRead,%ProjectDir%AppsAnyAppApp.script,Main,Selected,%Scrip_Selected%
IniRead,%ProjectDir%AppsAnyAppApp.script,Interface,pCheckBox1,%CheckBox1%
If,%Scrip_Selected%,Equal,True,Begin

// SET A CHECKBOX ACCORDING TO SETTINGS IN ANOTHER SCRIPT //
If,%CheckBox1%,Equal,True,IniWrite,%ScriptFile%,Interface,pMyCheckBox,"Option1,1,3,300,20,250,20,True"

// SET A CHECKBOX IN ANOTHER SCRIPT //
If,%CheckBox1%,Equal,True,If,ExistFile,%ProjectDir%AppsAnyAppSomeOtherApp.script,IniWrite,%ProjectDir%AppsAnyAppSomeOtherApp.script,Interface,pMyCheckBox,"Option1,1,3,300,20,250,20,True"
Else
IniWrite,%ScriptFile%,Interface,pMyCheckBox,"Option1,1,3,300,%X%,250,20,False"
End
End

This approach unfortunately works only at runtime, not while configuring the scripts.
It's a way to prevent problems by bad choices, but since the user does not see, what is changed why, he/she will not be able to learn from it.

Also, if you have two conflicting options, with which one do you go?
Represents the first one or the later one, what the user would prefer?

first please keep in mind, that i see me as an typical enduser. maybe a little bit advanced, but an enduser.
i am no developer, i am no programmer. i don t want to know everything deep to the last detail, that i can finish my work.
i only want know so much, that i can finish my work, the rest, every detail is not important for me.
i don t like to get forced to learn every detail about something, only that i can work with it (the typical linux way).


in short words to the topic:
no, winbuilder isn t enduserfriendly. no piece, not at all.

i was looking for an way, to create the ulitimate win-live-system. for recovery, for diaganostic, for security (virusscan from outside the running o.s) and so an.
so i found winbuilder. the first trouble beganns with waik. it needs some files from what? waik ? what the hell is waik. reading, reading, reading.
then i managed to extract wim_boot and wim_install, what saves me a lot of time, becouse winbuilder is working faster with extractet wim-dirs, then it must not mount everything.
but ok, you have to know it...
i was looking for informations about winbuilder, so i found this board here.
all informations i found, were more pieces from things i didin t understood.
i had try to abstract them for my case of use and tried everything by myself, to find working solutions for my needs.
i must modify scripts that they work correctly. therfore i was must learn about the syntax, commands and so on of the scripting langauge.
much, much work.
and there are still many, many sticking points more for the enduser.

if you use winbuilder in default for the specific project then ok, then you have not sooo much work.
its creating then just a default system for you. if this is enough for you, then you are fine.
but as soon you will edit it, that you can work with it (implement for example working viruscanners and other stuff you need),
then the easy is over. you must dig very deep under the surface and learn many, many things, without it you can t finish your work.
the portable apps script, is a good step into the right directy: implement stuff to your live system, without beeing an expert and know every detail, but its far away from beeing perfect.
till now, i am not able to getting specifc programms autostartet correctly wich need command-line-switches.
exampel: sysinternal processexplorer.
that i can use it correcty and it isn t disturbing, it must startet minimized in the tray.
the nice script wich exists for this progamm can only autostart it maximized.
then it pops up every time if you start you live system. not acceptable for me.
process-explorer need the commandline-switch (/t) to start minimized, but till now i haven t found a way to implement that....
and so things goes on, wich make winbuilder not very userfriendly, also if this this is maybe a strange example. but this are the things, wich concern me as enduser, to finish my job.

so don t understund me worng.
i have excelled my expectations completly.
but the price was to spend many, many, many, many time to know how winbuilder works and i am still a bloody beginner. learn about script-syntax and grub4dos-stuff and so on.
winbuilder is really a nice project and i like it. but before you can use it for indivudal projects, you have to spend time, time and time.

best regards
parkuhr

Edited by livedude, 27 March 2012 - 04:58 PM.

what the hell is waik. reading, reading, reading
...
but as soon you will edit it, that you can work with it (implement for example working viruscanners and stuff),
then the easy is over. you must dig very deep under the surface and learn many, many things, without them you can t finish you work.

For me the post is not "About WinBuilder", but about a certain WinBuilder based project (E.g. WinBuilder does not have any idea / knowledge about WAIK).
WinBulder is "Only a stupid batch processor" like cmd.exe but with different and much more (powerful) commands.

Your critics should be directed to certain (named) projects.
Also the projects are very different seen to their simplicity, user friendness, easyness to add a new script.
But adding a script is not simply a "Do this!"
As told above, WinBuilder has a lot of powerful commands, you have to know when writing a new script. The complexity and syntax of the commands is comparable with high level programming languages, like Java, Basic, c, ...
And I never heared that some serious programmer complains about "basic is not user friendly"

Peter

At least your problem with the board can be explained by the fact, that this is mainly a development board, which does on the side some support.

Definitly not the best possible place for a beginner to learn about Winbuilder and it's projects. I absolutely agree.
Unfortunately there is nothing that can be done about it. The active community is just too small. It's a wonder, we can keep the projects going and are able to give any support at all.

On the other point, that WB isn't easy for creating a own project with own scripts.
I can not agree so much. Comparing it with similar tools, i find WB pretty easy to use.

Thank you guys for the constructive and friendly feedback.
Peter is correct, if you see it from his point, my critics (not meand in a bad way, i only talk about my experiences as a typical enduser), affect also specific projects.
in my case win7PE_SE.

another example to understund better what i mean.
back to sticking points:


i found out that there are two ways to build a project:

wim-boot (in ram)
normal

if you build now a wimboot-project, you will find out soon, that your live system needs much ram that it can start. i gues 800 till a 1gb!
thats to much. my live system should run on so many plattforms a possible.
but if you build a normal project then it runs with much less ram then a wimb-boot-project.
but and this is the point:
you don t have a mutiboot-system
you not have menu at starting your system in wich you can choose what you want start.
nice thing.
so i tried first that:
i build a normal system saved the iso and then i build a multiboot (wimboot) and implement the bevor createt normal build iso. into the multisystem, with an entry in startmenue for it.
well big cinema, then if you try to start a win7pe-system wich is build in normal boot out of the bootmenu, you get this not acesable bsod07).
has propably something to do with bootcode/bootsector/mbr and stuff.
so nothing was it.
i tried a long, long time. then i found finaly out, that i can first build a normal build system, change winbuilder then to multiboot and bind my others programm into it with bootmenu entrys. the so createt win7-pe-system runs with about 256mb ram and i have a bootmenu with wich i can start other isos.
it costet me about 3 days and 3 worked nights to find that out. of couse i had also to edit scripts a little bit that this method worked...
i don t think that these things are only problems from the project you use, like win7pe_se. i think thats concern more winbuilder by it self.
and so the story goes on, there are many, many, others example i can tell you.
like i said, there are many, many sticking points!




best regards

live dude

Edited by livedude, 27 March 2012 - 05:32 PM.

The 'problem' you've run into is, that you wanted to use a very advanced setup. One that is possible, but no projects is specificly build for.

I guess most developers don't waste time on making such a setup easy, because this is not for beginners, this is for advanced users and advanced users won't be happy with a simple generic setup. They want one, that's specificly taylored to their needs, something no project maintainer can deliver.

The 'problem' you've run into is, that you wanted to use a very advanced setup

sorry but i don t agree.
i think not that it is an advanced wish, to have an live system wich works on as many different plattforms as possible and wich need not much ram that it can finish its job.
this was one of my wishes as i startet my project and i don t think, that am the only not so advanced user with that concern.

best regards

livedude

Edited by livedude, 27 March 2012 - 05:53 PM.

Appearantly we did misunderstand eachother.
I was not talking about a PE which uses little resources. This is of course a very simple request and one, which all projects can quite easily provide, imo, if not setup to do so by default.

PE1 (XP) based projects build by default a PE, which requires very little RAM.
PE2 (Vista) and PE3 (Win7) based projects, have a slightly different philosophy and build by default a PE, which runs best, but also needs way more RAM.

I was talking about your multiboot wishes.

thanks for explanation the different project types and philosphy behind it. i am glad that i have that info now and i think, it belongs to the basic;)
well for me it is no opposition to have on the one hand an full-win7-live-system (wich need as less resouces than possible) and on the other, the posibility to start other apps directly, if you have tasks, for wich is not necesary to boot the wohle live-system, for example partition a hdd.
so it was clear for me to make a project in wich both is possible: to have a win7-live-system wich need not much resources and to have the posibility to start needed programms directly from a bootmenu.
but ok, on the technical side, there seems this is a big different. sorry, i see it from the typical enduser-view and i am grapeful for all the work people spend in this great project. if you know how to work with it and modifying things so that you can build an project for your needs, then winbuilder is fantastic;) but till you are at this point, its a far road,you have much work, spending time reading stuff and so on.

best regards

livedude

Edited by livedude, 27 March 2012 - 08:11 PM.