[Bitpim-devel] How to tell users about files Sanyo phones don't want

[Stephen Wood]

When trying writing a media file to a Sanyo phone, the phone may reject
the file for various reasons. These reasons include wrong file type
(only PNG and MIDI seem to be allowed), too many files of that type are
on the phone (~6 ringers and ~11 wallpaper seem to be the limit), the
images or files are too large, or the phone just feels like being
unhelpful.

I am looking for suggestions of how to notify the user of which files
were rejected and the reasons. The goal is to do something such that
things will be clear to users who havn't read the help (so as to
minimize questions to the mailing lists), yet not be to obtrusive to
experienced users familiar with the limitations of the Sanyo phones.

Right now, the BitPim Sanyo code just prints out the error codes into
the Log pane. My next obvious step is to translate the error codes into
explanations. But I am wondering if I should pop up an
information/error window at the end of the transfer process that lists
which files were not transferred and why.

Stephen

[Adit Panchal]

Post by Stephen Wood
But I am wondering if I should pop up an
information/error window at the end of the transfer process that lists
which files were not transferred and why.

Yes, the best way would just be to pop up a regular dialog box that
lists the error number (if necessary) and the meaning of the error.
Then list the the files that were not transferred successfully. That
way, new users would just read the message and understand what happened
and experienced users would just press "OK" to get out of the box
without really bothering with it. Anything more complicated would
either be a hindrance to experienced users and too possibly too
confusing to new users.

For example:

"Sanyo Error Code 106: Small ringer memory full. You have filled the
maximum amount of small (<20 KB) ringers that the phone can handle. In
order to transfer additional ringers to the phone please delete an
existing ringer and try transferring again. You can delete a ringer on
the phone by going to the PC Sync Menu and selecting the ringer you
wish to delete.

Files not transferred:
abc123.mid
def456.mid"

I hope I didn't state something that was blatantly obvious. :)

Adit

[Roger Binns]

Post by Adit Panchal

Post by Stephen Wood
But I am wondering if I should pop up an
information/error window at the end of the transfer process that lists
which files were not transferred and why.

Yes, the best way would just be to pop up a regular dialog box that
lists the error number (if necessary) and the meaning of the error.

Things aren't as trivial as you think since there are multiple threads
involved and restrictions on which threads can do gui stuff :-)

The first question is if we display this stuff while the
transfer is happening, or just one big notification at the
end. Everybody seems to (implicitly prefer the end).

The way I want to do it is by having an HTML widget contain
the details of what has happened. That can then include
links to the help etc.

The best design would seem to be to have a file in the resources
directory with HTML fragments. To use Adit's example, it could
start like this:

<SANYO_SMALL_RINGER_MEMORY_FULL>
<p>Small ringer memory full.

<p>You have filled the
maximum amount of small (&lt;20 KB) ringers that the phone can handle.
<a href="bitpimhelp:sanyo_small_ringer_memory_full">More details ...</a>

<p>Files not transferred:

%%files|list%%
</SANYO_SMALL_RINGER_MEMORY_FULL>

We can then add another key to the dict that is flung around everywhere.
Lets call the key "messages".

You would then do something like

results["messages"].append("SANYO_SMALL_RINGER_MEMORY_FULL",
{"files": ["file1.mid", "file2.mid"]})

In the substitutions, "files" is the key to extract from the dict
of parameters and "list" says how to format it (as an HTML list).
The bitpimhelp: scheme will bring up the online help on that
particular topic and contain the rest of the explanatory text.

Ideally I would like to do this with all error messages and
similar program generated text eventually.

Anyone have any comments/praise/criticism?

One thing that is going to be required is an auto-resizing
HTML widget. I have been wanting one for ages anyway and
know roughly how to do it.

Post by Adit Panchal
without really bothering with it. Anything more complicated would
either be a hindrance to experienced users and too possibly too
confusing to new users.

I am currently finishing up code to import Qtopia desktop (Zaurus).
Next I am going to work on vcard import, and then I will do this.

Post by Adit Panchal
I hope I didn't state something that was blatantly obvious. :)

Nope :-) BTW are you happy with me doing vcard export before CSV
export? I am actually hoping to only do vcard export.

Roger

[Adit Panchal]

Post by Roger Binns
In the substitutions, "files" is the key to extract from the dict
of parameters and "list" says how to format it (as an HTML list).
The bitpimhelp: scheme will bring up the online help on that
particular topic and contain the rest of the explanatory text.
Ideally I would like to do this with all error messages and
similar program generated text eventually.
Anyone have any comments/praise/criticism?

This sounds like a good idea. Keeping the error info in the help as
well makes the most sense as users can use it as a reference. I was
curious though on how you think the html widget should be displayed.
Will it be in a separate window of its own? I would assume so - I don't
really see how to integrate it into the main window. Plus that would
seem to make the error less important if it was part of the main app
window itself (my personal opinion).

Post by Roger Binns
I am currently finishing up code to import Qtopia desktop (Zaurus).
Next I am going to work on vcard import, and then I will do this.

Do you mean vCard import or export (also referring to below)?

Post by Roger Binns
Nope :-) BTW are you happy with me doing vcard export before CSV
export? I am actually hoping to only do vcard export.

That is fine. I have an exam in August that will be coming up before I
know it so I am going to keep poking at this merging code in the
meantime. If you still want me to write the CSV export, I still have my
stub code that I can work from. Although, now I am not sure if it will
be ok to use, since the import has changed some (from just CSV to
generic import with derived import routines)?

Adit

[Roger Binns]

Post by Adit Panchal
This sounds like a good idea. Keeping the error info in the help as
well makes the most sense as users can use it as a reference.

The idea is that a short message exists as an HTML template.
All the fragments are glued together and displayed as one
message.

The help then contains the longer details and explanation and
is linked to from the above.

Post by Adit Panchal
I was
curious though on how you think the html widget should be displayed.

It would just be part of a standard dialog box. Something like
the About dialog. I do anticipate making it more complicated in
the future. Eg the first line of each fragment could be used
to display a summary at the top, and link to the fuller text
in a "display details ..." sort of thing.

Post by Adit Panchal
Do you mean vCard import or export (also referring to below)?

Sorry, I meant vCard export. There haven't been any bug reports
for vCard import, and the only remaining thing is dealing with
the Photo attribute Mac vCards have.

Post by Adit Panchal
meantime. If you still want me to write the CSV export,

Do you still want CSV export? I think all the programs
out there can handle vCard importing anyway.

And is it just me or is Outlook really stupid when dealing
with vCards? It only reads the first one in a file,
and only imports one file at a time (although it lets you
select multiple files). The importer also appears to
be *way* slower than BitPim's.

Post by Adit Panchal
Although, now I am not sure if it will
be ok to use, since the import has changed some (from just CSV to
generic import with derived import routines)?

Once I have the UI in place for vCard export you'll get
an idea of what I have in mind.

Roger

[Stephen Wood]

On Sat, 2004-06-26 at 01:26, Roger Binns wrote:
...

Post by Roger Binns
You would then do something like
results["messages"].append("SANYO_SMALL_RINGER_MEMORY_FULL",
{"files": ["file1.mid", "file2.mid"]})

...

Post by Roger Binns
Anyone have any comments/praise/criticism?

I think this is a great idea. I could even start adding stuff to the
dictionary now, assuming that it won't break anything.

But I'll have very little time to work on BitPim over the next month and
a half, so I won't be able to help write a message display subsystem
soon. But since I believe that the limitations of writing to Sanyo
phones will continue to be a source of confusion, I want to make sure
that I explain the Sanyo errors and that users have a decent probability
of seeing those explanations.

Stephen

[Roger Binns]

Post by Stephen Wood
...

Post by Roger Binns
You would then do something like
results["messages"].append("SANYO_SMALL_RINGER_MEMORY_FULL",
{"files": ["file1.mid", "file2.mid"]})

...

Post by Roger Binns
Anyone have any comments/praise/criticism?

I think this is a great idea. I could even start adding stuff to the
dictionary now, assuming that it won't break anything.

Ok, go for it. We should probably use a different key though. I
want to add the following datatypes in the future:

- SMS messages
- text memos
- voice memos
- call history

Use a key of "_messages". We'll use a convention that anything in
the dictionary that begins with an underscore is not actual phone
data, but metadata like these messages, or a flag. (Yes, I'll change
then phone reboot one as well).

Post by Stephen Wood
But I'll have very little time to work on BitPim over the next month and
a half, so I won't be able to help write a message display subsystem
soon.

No, problem. I will do it.

Post by Stephen Wood
But since I believe that the limitations of writing to Sanyo
phones will continue to be a source of confusion, I want to make sure
that I explain the Sanyo errors and that users have a decent probability
of seeing those explanations.

For the moment, don't generate an exception and put something distinctive
in the log, and ensure there is a help page that can be linked to.

Roger