Ubuntu should have better links to support options

Yes, but it's on MY wishlist ;-) so I've added it to Dapper. Easy enough to do menu entries that target known URL's. Sebastien, please could you upload the menu reorg that I've described above, and point the two URLs at:

  http://help.ubuntu.com/
  http://www.ubuntu.com/support/marketplace/

I've put that on my TODO list. Do we have any nice icons we could use for those menus items or somebody we could ping about that?

Launchpad question, do we need 2 tasks for that? Is one task with a dapper milestone enough?

I don't have any good icons, make a note to fix that for the UI sprint :-)

In theory, fixing something in Dapper in Malone should also mark it
fixed in Ubuntu generally, since Dapper is the development release
("head") for Ubuntu.

Mark

> In theory, fixing something in Dapper in Malone should also mark it fixed in Ubuntu generally, since
> Dapper is the development release ("head") for Ubuntu.

I'm not sure this is true. We often fix bugs in the current development release that we have no intention of fixing in older releases. I suspect the bug tracker should still know this and just age out the bugs as we expire old releases.

Tks,
Jeff Bailey

Would it be posible to create a link in a menu like you talk about. A link to ubuntu-forum in the default language?
In a
german system: System->Help->german ubuntu-forum
french system: System->Help->french ubuntu-forum
and so on...
This would be very easy, so everybody can find very fast help (also dummies)....

One of the pages I described would have the ability to detect languages
and point you at relevant sources of support in your local language. I'd
rather do that than have a dedicated Forums-link-per-language in the OS.

Jeff I think you misunderstood me. If there are tasks on "Ubuntu",
"Ubuntu Dapper" and "Ubuntu Breezy" (the last one being a "please
backport this fix" task), the second one being a "we need this fixed in
Dapper before release" task, then marking it fixed in Dapper should also
mark if fixed in "Ubuntu", but not in "Ubuntu Breezy". The "Ubuntu
Breezy" fix is separate, it requires special attention. Make more sense?

Rejecting as there is already an Ubuntu task open on this bug.

 affects /distros/ubuntu/dapper
 status confirmed

Sorry, Kiko, but a Dapper bugtask implies that the bug should be fixed
in Dapper, which is my requirement. We should be using proper release
targeting of bugs (see my Malone priorities for further comment).

Mark, for what should we use the milestone so?

Sebastien, you can target bugs and specs to a milestone, I believe. Then
you can track your progress against that milestone. So for example, you
could say "here are all the bugs I want to fix n Flight 5", then you can
keep reloading that page to see how it is going. At the moment, we are
not using milestone and release/series targeting very effectively.

That upload fixes the issue:

 gnome-panel (2.13.91-0ubuntu6) dapper; urgency=low
 .
   * debian/patches/09_help_submenu.patch:
     - make a "help" submenu for support (Ubuntu: #31775)

I let the bug open in case we want to tweak the icons and labels for it, if not feel free to close it

I filed a bug on this without seeing this bug, thanks to Daniel for pointing it out. I'll repeat my comments here.

The new help submenu in the System menu is fantastic. I have an idea to improve it.

The current setup is:

 * System Documentation
 * Online Support (http://help.ubuntu.com)
 * Find Local Help (http://www.ubuntu.com/support/marketplace)

Some comments first - The second link is documentation only. I'd suggest pointing to a link which lists all the free support options (documentation/launchpad tickets/forums/irc). The third link points at commercial help, I'd suggest making a separate entry for this, and pointing the Local Help icon at the list of free local support options. So here is my idea:

 * System Documentation
 * Online Support (http://www.ubuntu.com/support/supportoptions/freesupport)
 * Find Local Help (http://www.ubuntu.com/support/supportoptions/local)
 * Commercial Support (http://www.ubuntu.com/support/marketplace)

I've made a patch for this[1]. It is not completely ready: it needs a different icon added for the Commercial Support link. I don't know how to do that, so I gave it the same icon as for the Online Support.

[1] http://librarian.launchpad.net/1645166/help.menu.mdke.patch

Hope this helps,

Matt

We were just discussing the changes of the Help menu and we might need a bunch of changes.

 * Documentation
 * Online Documentation (which would mean help.ubuntu.com)
 * Free (Community) Support
 * Find (Commercial) Technical Support

The problem is the naming of the links. Some things we noted while thinking about it:
 * Online Documentation might be considered to be "Online Help (handbooks on the disk)"
 * Does 'Community' mean much to people like my parents
 * Isn't Support always considered something you pay for?
 * How do we put all this meaning in short titles which can be distinguished.

We'd also need descrptive tooltip texts and maybe some changes in the chosen icons.

I think "Online Documentation" works fine. For the others, I'd recommend (as per my comment above) "Community Support" and "Commercial Support".

I think "Community" is clear enough.

But, please please please make a link for finding Local Support: it's very important that people have an immediate way of finding the right language.

On Tue, Mar 07, 2006 at 02:56:57PM -0000, Matthew East wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/31775
>
> Comment:
> I think "Online Documentation" works fine. For the others, I'd recommend
> (as per my comment above) "Community Support" and "Commercial Support".
>
> I think "Community" is clear enough.

I disagree; this concept of "Community" is a strong one within the Ubuntu
community, but not with the rest of the world.

The difference between these two options is that one of them provides a
means of asking other users for assistance, while another provides
technical support services.

> But, please please please make a link for finding Local Support: it's
> very important that people have an immediate way of finding the right
> language.

Why would you ever want support which was *not* in the right language? All
of the support options should take this into account; I don't see why it
should be a separate option in its own right.

--
 - mdz

Sorry for not quoting, I don't know how to use malone's email interface yet.

On the "Community" point you make, that's fine by me.

However "Technical" does not go anywhere towards establishing that that service is a paid for one. Both free and commercial support can be "technical". So, something like:

"Free (Community) Support"
"Commercial Support"

would work I think.

On the local language point, you're right: if the URIs can be localised, then that is no problem. But if they can't, a link to an English webpage with a link at the bottom to another page which has various languages on it is nowhere near as good as a link to the latter page straight away. In the first case, the user who doesn't speak any English has no change of finding the right page.

Matt

On Tue, Mar 07, 2006 at 03:48:07PM -0000, Matthew East wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/31775
>
> Comment:
> Sorry for not quoting, I don't know how to use malone's email interface
> yet.

You need only reply to the email as you would any other.

> On the "Community" point you make, that's fine by me.
>
> However "Technical" does not go anywhere towards establishing that that
> service is a paid for one. Both free and commercial support can be
> "technical". So, something like:

I disagree; there is a strong connotation in English that "technical
support" is a helpdesk type service, in contrast to the kind of help that
one can get by asking family, friends, neighbors, etc. (which is what we
mean by the "community" option)

There are many important distinctions between "community" support (asking
other users for help) and "commercial" support (technical support / helpdesk
services), beyond the question of money. For this reason, I think they
should be named more distinctly.

> "Free (Community) Support"
> "Commercial Support"
>
> would work I think.

My preferred terminology, all other concerns being equal, would be something
like:

"Ask other Ubuntu users for help"
"Contact a technical support service"

However, these are too long for the menu (they would make good tooltips, but
that is no substitute for a clear and concise menu item).

> On the local language point, you're right: if the URIs can be localised,
> then that is no problem. But if they can't, a link to an English webpage
> with a link at the bottom to another page which has various languages on
> it is nowhere near as good as a link to the latter page straight away.
> In the first case, the user who doesn't speak any English has no change
> of finding the right page.

If the browser language preferences are not sufficient, then localizing the
URLs is straightforward with a helper program. The user has already told
Ubuntu the language in which they prefer to be addressed, and we should
respect that preference without asking again.

--
 - mdz

To add another twist to this, please make sure there are sensible
defaults when the users clicks on those menu items and isn't online at
the time.

Asking for support and being taken to an error page in the browser isn't
very helpful. Can we detect if the user isn't online at the time and
put up a fixed page?

On Tue, 2006-03-07 at 17:18 +0000, Matt Zimmerman wrote:

> On Tue, Mar 07, 2006 at 03:48:07PM -0000, Matthew East wrote:

> > On the "Community" point you make, that's fine by me.
> >
> > However "Technical" does not go anywhere towards establishing that that
> > service is a paid for one. Both free and commercial support can be
> > "technical". So, something like:
>
> I disagree; there is a strong connotation in English that "technical
> support" is a helpdesk type service, in contrast to the kind of help that
> one can get by asking family, friends, neighbors, etc. (which is what we
> mean by the "community" option)

I'm not really convinced by this, although of course the decision will
be up to you. I agree that "community" has a different feel to
professional support, but I don't believe the word "technical"
represents the difference. Indeed, the forums regard their help as of a
"technical/helpdesk" nature. What we are really getting at is the
difference between "community" and "professional". "Technical" doesn't
go near that, at least in my understanding of how the word is generally
used.

> There are many important distinctions between "community" support (asking
> other users for help) and "commercial" support (technical support / helpdesk
> services), beyond the question of money. For this reason, I think they
> should be named more distinctly.

I completely agree: indeed that is why I suggested title based on "Free
Support" and "Commercial Support". You are right that it isn't always
simply a question of money (subject to the caveat that there is probably
nothing to stop a community member asking to be added to the
marketplace, and charging for support), but I think those simple titles,
expanded upon by tooltips along the lines of those you suggested, would
work really well.

> > On the local language point, you're right: if the URIs can be localised,
> > then that is no problem. But if they can't, a link to an English webpage
> > with a link at the bottom to another page which has various languages on
> > it is nowhere near as good as a link to the latter page straight away.
> > In the first case, the user who doesn't speak any English has no change
> > of finding the right page.
>
> If the browser language preferences are not sufficient, then localizing the
> URLs is straightforward with a helper program. The user has already told
> Ubuntu the language in which they prefer to be addressed, and we should
> respect that preference without asking again.

Ok, if localizing the URLs is possible, we could work with Seb to make a
page for each localisation on the website.

Matt
--
<email address hidden>
gnupg pub 1024D/0E6B06FF

On Tue, Mar 07, 2006 at 05:27:05PM -0000, Jane Silber wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/31775
>
> Comment:
> To add another twist to this, please make sure there are sensible
> defaults when the users clicks on those menu items and isn't online at
> the time.
>
> Asking for support and being taken to an error page in the browser isn't
> very helpful. Can we detect if the user isn't online at the time and
> put up a fixed page?

This would be possible with a helper program, but what Mark asked for was a
trivial feature with static URLs.

It is not trivial to make these menu items behave correctly with respect to
the user's language settings and Internet connectivity, and we shouldn't
force non-trivial features into Dapper at this late stage without more
thorough consideration.

I'm happy to debate the ideal solution, but as concerns Dapper, we don't
really have the option of an ideal solution.

--
 - mdz

On Tue, Mar 07, 2006 at 05:30:05PM -0000, Matthew East wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/31775
>
> Comment:
> On Tue, 2006-03-07 at 17:18 +0000, Matt Zimmerman wrote:
> What we are really getting at is the
> difference between "community" and "professional".

Correct.

> "Technical" doesn't go near that, at least in my understanding of how the
> word is generally used.

Certainly not; that isn't what I meant. "technical support" is more than
the sum of "technical" and "support".

> > There are many important distinctions between "community" support (asking
> > other users for help) and "commercial" support (technical support / helpdesk
> > services), beyond the question of money. For this reason, I think they
> > should be named more distinctly.
>
> I completely agree: indeed that is why I suggested title based on "Free
> Support" and "Commercial Support". You are right that it isn't always
> simply a question of money (subject to the caveat that there is probably
> nothing to stop a community member asking to be added to the
> marketplace, and charging for support), but I think those simple titles,
> expanded upon by tooltips along the lines of those you suggested, would
> work really well.

The only difference between those two phrases is the word "free" vs. the
word "commercial", which is solely a matter of money, which is why I am
still interested in other suggestions.

--
 - mdz

Another last quick idea on this. In fact, the documentation on http://help.ubuntu.com identically reproduces the documentation available in the distribution (except without all the extra system stuff) - so really two separate entries for this are not necessary, especially considering as Jane mentioned that one is unavailable to our offline users.

So, we can eliminate the help.ubuntu.com link, in my opinion, in any event it is covered by the "Free Community Support" web page. That leaves a bit of space for a local entry, if localising the URI provides too difficult, as Matt suggested in his more recent comment it might be.

Matt

On Tue, Mar 07, 2006 at 11:22:53PM -0000, Matthew East wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/31775
>
> Comment:
> Another last quick idea on this. In fact, the documentation on
> http://help.ubuntu.com identically reproduces the documentation
> available in the distribution (except without all the extra system
> stuff) - so really two separate entries for this are not necessary,
> especially considering as Jane mentioned that one is unavailable to our
> offline users.

If the help.ubuntu.com content will always be identical to the ubuntu-docs
content, what is its purpose? I assumed it would be more frequently
updated.

Note that during the UI sprint, it was proposed that the link should be
specific to Dapper (e.g., http://help.ubuntu.com/6.04), so that we can
permanently present the Dapper content there as the documentation evolves
for future releases.

--
 - mdz

On Wed, 2006-03-08 at 10:09 +0000, Matt Zimmerman wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/31775
>
> Comment:
> On Tue, Mar 07, 2006 at 11:22:53PM -0000, Matthew East wrote:
> > Public bug report changed:
> > https://launchpad.net/malone/bugs/31775
> >
> > Comment:
> > Another last quick idea on this. In fact, the documentation on
> > http://help.ubuntu.com identically reproduces the documentation
> > available in the distribution (except without all the extra system
> > stuff) - so really two separate entries for this are not necessary,
> > especially considering as Jane mentioned that one is unavailable to our
> > offline users.
>
> If the help.ubuntu.com content will always be identical to the ubuntu-docs
> content, what is its purpose? I assumed it would be more frequently
> updated.

It isn't more frequently updated, it just contains the stable docs
(which don't change). Its purpose is to provide an online home for the
ubuntu specific guides which exist on the local system for two
categories of people (that I can think of):

 * people who don't run Ubuntu when they are reading them
 * people who don't use the onboard documentation because they (a) don't
know about it, (b) don't like yelp, or (c) are simply used to reading
documentation online.

I suppose also it helps to have a url for people to link to in their
other documentation/weblogs/websites etc.

There is just about a justification for it :) And in the long run, we
hope that the wiki documentation will be at the same website.

However, right now, I don't think there is a justification for two links
in the distro itself, because people seeing the links will be able to
access the onboard documentation.

> Note that during the UI sprint, it was proposed that the link should be
> specific to Dapper (e.g., http://help.ubuntu.com/6.04), so that we can
> permanently present the Dapper content there as the documentation evolves
> for future releases.

Yes, Seb informed me and this will be done. I've made a symlink at
http://help.ubuntu.com/Dapper to our work in progress site at
http://doc.ubuntu.com for now. This will change on release to the stable
docs.

Matt
--
<email address hidden>
gnupg pub 1024D/0E6B06FF

Seems to be fixed in current Dapper. Good work :-)

Actually, I'm not sure all of the conclusions in this bug report have been implemented. Have we arrived at the final version of this menu?

no, there is some changes still to do

Seb, thanks for making that clear. To add something to the mixture: the documentation website at http://help.ubuntu.com/6.06 will hopefully be fully localised for dapper, so in the event that you decide to keep this link, it will be localised.

(However, the material on the website will still just be a duplicate of the onboard documentation, so my view is still that one of these two links is enough, and the "Community Support" link should go to a page which includes other resources than just documentation).

I would like to update that today

We decided on something like those 4 menu items for it:
* Documentation running yelp
* Online Documentation pointing to http://help.ubuntu.com/Dapper/
* Free Support pointing to ... ?
* Find Technical Support pointing to ...?

What should the the Free and Technical pages to point to? Could anybody come with correct english subtitle for those?

Some suggestions:

Free Community Support -> http://www.ubuntu.com/support/supportoptions/freesupport
Commercial Support -> http://www.ubuntu.com/support/supportoptions/paidsupport

As I believe I've said before on this bug, it's a shame to remove the "Local" link (http://www.ubuntu.com/support/supportoptions/local), unless the other links can be localised in some way.

Matt

We'll do a commercial support page that has local support options built
into it.

On Wed, 2006-04-12 at 11:20 +0000, Mark Shuttleworth wrote:
> We'll do a commercial support page that has local support options built
> into it.

How about the free one? Can we localise that too? I'm not too concerned
about the commercial support page, because that already has local
support options (marketplace). It would seem an awful lot simpler to me
to maintain the "Find Local Support" link, and kill the one to
http://help.ubuntu.com/6.06 (as mentioned, this is a duplicate of the
onboard documentation).

Matt
--
<email address hidden>
gnupg pub 1024D/0E6B06FF

Okay, here is the plan for the System->Help menu. It should contain the following 5 items. For each item I'll list
- the string for the menu
- the tool tip
- a link to open or app to invoke

Item 1:
- "System Documentation"
- "Get help with Ubuntu"
- the onboard documentation in Yelp (as currently implemented)

Item 2:
- "Online Documentation"
- "Find more documentation online"
- a link to help.ubuntu.com

Item 3:
- "Free Support"
- "Get help from other Ubuntu users"
- a link to http://www.ubuntu.com/support/supportoptions/freesupport

Item 4:
- "Commerical Support"
- "Find a commercial support provider"
- a link to http://www.ubuntu.com/support/marketplace

Item 5:
- "Ubuntu Book Excerpt"
- "Read selected book chapters"
- open the (soon to be packaged) HTML book content in a browser. We don't have the content yet, so a place holder needs to be created.

Seb - can you put this in place?

Thanks!

Sorry - last change, I promise!

Item 3 should be:
- "Community Support"
- "Get help from other Ubuntu users"
- a link to http://www.ubuntu.com/support/supportoptions/freesupport

Thanks for the descriptions Jane. I've updated the package;

 gnome-panel (2.14.1-0ubuntu12) dapper; urgency=low
 .
   * debian/patches/09_help_submenu.patch:
     - updated, new layout is the one that will be used for dapper,
       thanks to Jane Silber for the items description (Ubuntu: #31775)
     - the "Ubuntu Book Excerpt" item points to the firefox startup page
       for now, that's not a bug, it'll be updated before dapper

We picked some icons with Daniel, let me know if they should be changed for something else. The book item points to the firefox startup page for now, I'll update when the book package is uploaded

On Tue, May 16, 2006 at 04:18:41PM -0000, Sebastien Bacher wrote:
> Thanks for the descriptions Jane. I've updated the package;

Thanks for the quick response. Did you also notify translators of the
change?

--
 - mdz

Sure, I mail documentation team and translators for string or UI changes since we are frozen

> Sure, I mail documentation team and translators for string or UI changes since we are frozen

Hello Sebastian, where can I find this strings on rosetta ? for my language gnome-pannel resultes fully translated, so there are those new strings ?

Thank You

Vladimer

Carlos, Martin, do you have an idea of why rosetta didn't pick those gnome-panel change? The template is correctly built with those on my local build

On Sun, 2006-05-21 at 19:50 +0000, Sebastien Bacher wrote:
> Carlos, Martin, do you have an idea of why rosetta didn't pick those
> gnome-panel change? The template is correctly built with those on my
> local build

FWIW: it appeared in Rosetta quickly, but since then seems to have
disappeared, from what people seem to have reported.

Matt
--
<email address hidden>
gnupg pub 1024D/0E6B06FF

Found the problem and fixed Rosetta.

The i386 build generated a bad .pot file that was missing those strings and thus, it hide them.

I just upload a fixed .pot file by hand and notified pitti about the problem.

Cheers.

Carlos, those strings ("Online Documentation", "Community Support", and so) are fully translated into Spanish since several days ago (maybe six or seven, at least):

https://launchpad.net/distros/ubuntu/dapper/+source/gnome-panel/+pots/gnome-panel-2.0/es/+translate?offset=345

However, the translations of those strings are not in the .mo file, so the System->Help is not translated in my Spanish desktop (except "System documentation").

I'm using the last updated langpacks from
http://people.ubuntu.com/~pitti/langpacks/daily/

What is it wrong?

there were not translatable until today, please try again after the next language-packs update