Christof Pintaske wrote:
> Garrett D'Amore wrote:
>> 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.
>
> if you click of one of the search results in command assistant then a
> browser window will open and bring you to the corresponding document.
> It's the same thing as with google. You see all the results and then
> you click on the ones where you are interested in. And then you see
> the full document. The search results in the app are always just an
> intermediate step, they are hardly useful by them selfs. I may sound
> like a broken record, but it's just like any other search engine.
But its not. The search engine is entered like a browser ... its
entered into as a desktop app. Actually, if you used a server based
technology and the user saw he was in a web browser when he typed his
search results, with the attendant expectations, it would probably not
be a big deal. And, you wouldn't need to come to PSARC either (most
likely). :-)
>
>>>> 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.
>
> The software itself is an open source project. And anybody can submit
> documents to the documentation community. If they are solbook then
> we'll be happy to index them. Where do you see architectural
> constraints or problems?
I'm not sure if its architectural, but the issue is the process -- who
makes the decision about whether a document will be indexed or not?
What happens if Sun decides to stop funding the work to support third
party document contributions?
If the infrastructure were hosted externally (on opensolaris.org
instead of opensolaris.com), with the ability for external parties to
participate in the administration and decision making, then you wouldn't
be hearing these complaints from me.
>
>>> 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.
>
> can you elaborate what you mean by "manage"? As described above the
> community is very well able to get involved.
They can't exercise any administrative control over any of the content.
The infrastructure is run totally at the whim of SMI.
Btw, since its hosted on opensolaris.com, perhaps the graphic in the
toolbar should say "opensolaris.com" instead of "opensolaris.org". :-)
These details may not be important to you, but rest assured that I've
heard from a number of community members that this *kind* of issue (not
necessarily this case in particular) is very important to them.
-- Garrett
>
> best regards
> Christof
>
>
>>>> 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.)
>>>>>
>>>>>
>>>>
>>>
>>
>
