Re: trying to understand context creation

[Jussi Kukkonen <jussi.kukkonen@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 3650 bytes --]

On Fri, Feb 24, 2012 at 7:12 AM, Denis Kenzior <denkenz@gmail.com> wrote:
>> I'm trying to improve the two problem cases:
>>  1. user has to run 3G wizard and makes poor selections
>>  2. There's a HW problem
>> As far as I can see the only way to do that is to fail as early as
>> possible. Currently we fail as late as possible and that's a confusing
>> user experience.
>
> I don't see how you are ever going to fix the HW problem part with a
> better 3G settings wizard.  If it doesn't work, no amount of helpful UIs
> will make it work.

User experience issues have more shades of grey than middleware
issues... Failing early and clearly is significantly better UX than
failing but leading the user to believe things work. I'm not "fixing"
HW problems any more than I'm "fixing" connman crashes in my UI --
both are still events I'd rather handle (witihin limits) if that makes
the UX better.

> And if the user is entering information without good understanding of
> the questions he's answering then either the provisioning database needs
> to be updated or we should be asking better questions.
>
> Of course, preferably we shouldn't even ask the user any questions if
> possible ;)

We are in total agreement. I will gladly remove this whole UI when you
or someone else with knowledge on this tells me that ofono + mbpi can
handle things. Likewise, if you tell me I can drop the manual settings
part and that won't harm many users, I will do it in a heart beat.

>>> Look at iOS for a
>>> good example, the user doesn't have any UI to edit context settings, it
>>> is all provisioned using carrier profiles.  Granted, the provisioning
>>> database in use is a little bit better than what
>>> mobile-broadband-provider-info provides, so some way to manually enter
>>> details would still be required in our case; however we should strive to
>>> make this as rarely used as possible.
>>>
>>> What you suggest is a good idea, but might be overkill...
>>
>> Since we have to let the user make a choice on something he does not
>> understand, I don't see good alternatives: currently we do the worst
>> possible thing: claim that everything is ok (by accepting the APN
>> settings and even showing the cellular service) and then later fail
>> when connecting -- and user has absolutely no way of knowing what the
>> failure was about*. I'll gladly take suggestions for simpler solutions
>> that lead to a UI that isn't confusing when things go wrong.
>>
>
> If the user doesn't understand the choices he's making, then no amount
> of helpful UIs will help here.  Imagine you walk into a store with a
> very helpful salesman, unfortunately you're speaking a different
> language.  If you don't have a very good idea of what you're looking
> for, there's nothing he can do to help you.
>
> My point here is that we should re-examine what we can do to make
> provisioning more fool proof, rather than trying to band-aid a settings
> UI that is inherently not understandable to anyone who isn't a GSM geek.

Yes, we should. As upstream project developers we have the luxury of
making statements like that (you here, I can do it in dawati-shell)
and that is definitely what actually improves the whole stack in the
long term.

Unfortunately I also have a role closer to an actual product where
"yeah, the provisioning should be better" is not an acceptable answer
to a bug report about the connectivity UI. My job is to make the UI
work as well as it can with the middleware and provisining db we have
right now. You can call it band-aiding but it's still my job.

- Jussi