OpenSolaris

Michael Pogue wrote:

<pre wrap="">Some additional comments on your comments below! Mike </pre>

<pre wrap="">5) I think this first page could use a title (e.g. "Select a language", or "select a locale"). </pre>

<pre wrap="">What language would you put it in? We could, of course, title the window with something like "Language". We are removing the specific concept of "locale" as it is confusing for many. Locale does make an implicit appearance later when the user selects the primary language to be used after rebooting - the language selection is paired with a country, but this does not require the use to understand "locale". </pre>

<pre wrap=""><!----> SuSE and Ubuntu both put the title in English. http://www.zenstarstudio.com/install/ubuntu.htm http://www.zenstarstudio.com/install/index.htm I don't think there's a perfect solution here, but having a title would be more consistent, I think. </pre>

If I recall properly the Mac doesn't label this window, but as I said we will likely title this window, in English.

<pre wrap=""> </pre>

<pre wrap="">7) Why are the first two pages completed with "OK", but the next pages completed with "Next>"? It seems to me that it might be more consistent to use "Next>" throughout. </pre>

<pre wrap="">As mentioned in another reply, the user can't return to these pages once they reach the Welcome page. </pre>

<pre wrap=""><!----> Hmmm...why is that? </pre> </blockquote> It's a separate application. Yes, it would be possible for the installer to call the language app, but it isn't worth the effort and schedule time at this point. We'll consider this in a subsequent release if it really turns out to be an issue.<br> <blockquote cite="midf82df28196 dot 461a1ec6 at sun dot com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">9) On the Disk page, the "type '=' into any partition size to adjust the available disk space" seems strange. What does it do? (I couldn't figure out how to type an equal sign into any Size field here). That would be a fairly non-standard thing to do -- what's the intent here? </pre> </blockquote> <pre wrap="">Typing "=" into any partition size field adjusts that partition's size by the "Available" size amount such that the available disk space goes to zero - no remaining unused/over allocated disk space. Save the user from having to do the mental arithmetic. There is a "bug" in the current implementation - changes should occur on the keystroke, not when the field looses focus. </pre> </blockquote> <pre wrap=""><!----> Hmmm... typing "=" into a numeric field is very non-intuitive to me. I don't recall any application ever doing this either. Perhaps it would be better to have buttons to do this? (BTW, I don't think it worked by losing focus either -- I tried that a couple of times, and it didn't do anything -- I could have missed this though?) </pre>

Having buttons creates their own problem - "what does this button do?" - and we would need four of them which would result in more screen clutter. Typing "=" may not be completely intuitive, but it can be ignored. The alternative is to do nothing and force all users to do the mental arithmetic. I'm definitely open to other approaches. The message wording next the "Available" field has be changed to "To adjust to zero, type "=" into any partition size."

<pre wrap=""> </pre>

<pre wrap="">10) If I have one active partition, and I make it smaller, </pre>

<pre wrap="">should the available space show up in the "Unused" partition? Or maybe, I'm not </pre>

<pre wrap="">sure how the "unused" partition type works, because its size field is greyed out and set to zero when I select "Unused". Don't "Unused" partitions also have sizes? </pre>

<pre wrap="">No, the released disk space shows up in Available at the bottom. We shouldn't presume the user is freeing up space for a new partition. They may be freeing it up to increase the size of another partition. Unused partitions do not have sizes. Again, the keystroke entry "bug" in Q9 is probably creating some confusion. </pre>

<pre wrap=""><!----> Hmmm...why don't unused partitions have sizes? That's unexpected for me. When I ran through the demo, I was trying to reserve some partitions for later use by Linux (which Solaris should consider "unused"), so forcing it to zero size was quite unexpected for me. </pre> </blockquote> These are fdisk partitions, not Solaris slices, which means that there can be four partitions - 'extended' partitions aren't supported in this release of the installer. "Unused" means that the partition doesn't exist. Any non-zero value in the size field means that the partition must have a type - untyped partitions can't be created. It seemed much more straight forward to provide the four fdisk partition entries, with ununsed entries labeled as "Unused" than to add a mechanism to add/delete entries. New partitions can be at another time by allocating space for them from the "Available" (unallocated) disk space. <br> <br> The installer's partitioning capability is admittedly quite weak: no extended partition, no split partitions, no dynamic relocation of partitions, etc.<br> <blockquote cite="midf82df28196 dot 461a1ec6 at sun dot com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">13) It could probably also be localized as per the initial two </pre> </blockquote> <pre wrap="">panels. (e.g. in Europe, the order is different from the US.) We don't want to force the user to specify a locale in addition to a language in the first panel. </pre> </blockquote> <pre wrap=""><!----> Then, YYYY-MM-DD doesn't show up, when non-English languages are in use, right? (Y/M/D are English-centric abbreviations). </pre>

The string "YYYY-MM-DD" will be adjusted as appropriate to the installer language, but the pattern will remain the same.

<pre wrap=""> </pre>

<pre wrap="">14) Hmmm...the Hour field is 0 - 12. That doesn't seem right. Are 0 AM and 0 PM both valid times? There is no 0 pm, but there are both 0 and 12 am depending on </pre>

<pre wrap="">12/24 hour time. </pre>

<pre wrap=""><!----> So, what happens if I select 0 PM (which the GUI allows)? Since the numbers 13-23 are not in the list, I assumed that 24-hour time entry was not possible.... </pre> </blockquote> Not yet fully implemented. Inserting numbers which are specific to only 24-hour time should force the drop-down to "24 hour".<br> <blockquote cite="midf82df28196 dot 461a1ec6 at sun dot com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">16) Might want to consider making the hour field and the AM/PM </pre> </blockquote> <pre wrap="">fields 24 hour in other locales (or maybe you already did this? I didn't check... :-) User selectable AM/PM/24. </pre> </blockquote> <pre wrap=""><!----> How do I get to the 24-hour time entry (from the English language installer)? </pre>

<pre wrap=""> </pre>

<pre wrap="">17) On the Users screen, if the passwords don't match for the user account, the error message is "User account error - must enter all or none of the user account information". This is fairly generic (and somewhat misleading). </pre>

This is initial "placeholder" message text. We're working with docs to improve the wording.

<pre wrap="">I think there's a much better way to handle errors: if the data </pre>

<pre wrap="">is invalid (e.g. passwords don't match), then don't enable the "Next>" </pre>

<pre wrap="">button. (Of course, make sure that there's a visible error message somewhere in this case.) When the data is there, the Next> button should be the default when ENTER is pressed. </pre>

<pre wrap="">Again, the user may not realize why the Next is not enabled even with a visible message. Users often don't look where we want them too. Myself included. ;-) We are working with the Docs folks to improve the message text. </pre>

<pre wrap=""><!----> I think that disabling the NEXT> button is a fairly standard way of doing this...I'm essentially asserting that users wouldn't have this problem, because this already occurs frequently. This would be a testable assertion, of course! :-) </pre> </blockquote> I suggest that if everything were always obvious to the user it wouldn't be necessary to disable the Next button because the user would never try to click the button when it was disabled. If the user wants to click a disabled button, then it isn't obvious and he will have to think about why is it so. :-)<br> <blockquote cite="midf82df28196 dot 461a1ec6 at sun dot com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">18) Same thing on the Install page -- if I haven't accepted the terms of the license agreement, don't enable the Install button for me. </pre> </blockquote> <pre wrap="">Again, we don't want to make the user guess. More work for us to add the extra error messages, but you'll note that we are allowing the user to accept the license within the dialog, which then proceeds to the next screen, rather than forcing the user to close the dialog, check the box, and click Install again. </pre> </blockquote> <pre wrap=""><!----> Yep -- it's probably more work either way. </pre>

Early experience showed that many users didn't see the License checkbox...
Overall definitely less work for the user, whatever path they take the installer adjusts, and that is what we want - low friction... ;-)

Frank

<pre wrap=""> </pre>