Christof Pintaske wrote:
> Garrett D'Amore wrote:
>>
>> I'm on sabbatical, so maybe all of this doesn't count. Nonetheless,
>> I'm unhappy that they still don't seem to have addressed a few (IMO)
>> key issues.
>>
>> a) Disconnect between software installed on the system, and
>> documentation presented. (I.e. examples can come from wrong versions
>> of Solaris, etc.) I worry that users can be presented with
>> information that is incorrect for their system, without any way of
>> knowing that this is the case.
>
> A browser window will open, guiding the user to a page on
> opensolaris.com. There he sees the actual document. This is in no ways
> different from any other search result. Why do you think a user would
> expect that a document in the internet is in line with what he has
> installed on his system? This model works fine for documents searched
> through Google, Yahoo, search.sun.com. Where do you expect an
> additional disconnect?
The screenshot wasn't reminiscent of a web browser, at least not to me.
The problem is not the presentation of the data, but in the presentation
of the search engine. The search engine feels like a desktop app, and
people won't have the same set of expectations that they do when
searching google, etc.
>
>> b) The inability for 3rd parties to contribute to the
>> documentation repository without Sun's involvement. I consider this
>> a critical failing for an "OpenSolaris.org" project. (Maybe this
>> should have been run as an entirely closed case, with no pretense
>> about being open.) Hosting on OpenSolaris.org (instead of .com), and
>> allowing other community members to help manage the content would
>> have alleviated that concern. The method by which ISVs and other
>> parties add to the documentation repository needs to at least be
>> spelled out, even if it *is* with Sun's intervention.
>
> A user can add to the repository by submitting the document to the
> opensolaris documentation community and notifying us. The number of
> submissions in that community is so low that I don't see that any
> further automation is justified (so far we haven't seen any document
> from the community that would be suitable).
I'm not looking for automation; I'm looking for it to be possible for
someone not employed by SMI to be able to participate in the process.
>
> Can you elaborate a bit more what you mean by "manage"? Typically the
> community does not manage the opensolaris infrastructure, like
> bugtracker, mailing lists, and so forth. Where do you see a specific
> need here?
>
> I don't see any architectural constraints that would prohibit a future
> closer community involvement. I would just like to postpone this
> discussion until the community shows interest and tells us how they
> would like to get involved.
If the service is managed exclusively by Sun, without any way for the
community to be involved, then its really just a Sun project and not an
OpenSolaris project.
>
>> Additionally after looking at the screen shot:
>>
>> c) The screen shot seems to indicate rather loose integration
>> with the desktop. The application doesn't seem to fit within the
>> desktop fit-and-feel (e.g. it doesn't look like it uses the stock
>> widgets). The toolbar integration looks (to me at least) like it is
>> just an icon on the toolbar that fires off the Java app, rather than
>> a first class resident of the toolbar (where the actual text entry
>> widget would live in the toolbar itself.) ISTR that the project team
>> indicated that this project had been reviewed by the appropriate UI
>> folks -- are the other ARC members satisfied? (I'm not enough of an
>> expert here to have a strong opinion about UI one way or the other....)
>
> I don't see a difference between the toolbar integration of the
> command assistant and other widgets like the deskbar applet, power
> manager, or netstatus applet. None of them has anything but an icon in
> the bar (just have a look at the deskbar applet which is a similar case).
>
> The xDesign people who we talked to did not express any concerns. Is
> there any other body that we have to consult for UI review?
Probably not --- this wasn't a serious concern.
As far as UI .. your screenshot looked like you weren't using any of the
standard gnome widgets, but had your own look and feel quite apart from
whatever gnome is using. That makes the application feel disconnected
from the rest of the desktop.
-- Garrett
>
> best regards
> Christof
>
>
>>
>> So, that said, I suppose I *could* be prepared to vote even without
>> answers to the above concerns, but the project team might prefer that
>> I didn't vote, at least not unless the project included TCRs to
>> address first two items.
>>
>> -- Garrett
>>
>> James Carlson wrote:
>>> The project team has asked that the ARC members review new materials
>>> in order to determine whether a formal commitment review is necessary.
>>>
>>> I've advised them to schedule a regular review, but I've also agreed
>>> to help them with this request, so I ask that all members expecting to
>>> vote on this case please review the updated documents in the
>>> 'post-inception.materials' directory, and then respond with an
>>> indication of whether you'd be ready to vote.
>>>
>>> Please provide a response either way by Tuesday, February 10th, so
>>> that we can have a vote in ARC business on the 11th.
>>>
>>> (I'm not asking for detailed issues or review comments; just an
>>> indication of whether you could vote on the materials as-is without a
>>> meeting. I'll call a vote if everyone agrees that they're ready.)
>>>
>>>
>>
>
