[dvdvol] Re: application update discussion

[Aaron Cannon]

You wrote:
"The other interesting thing is the way the system handles special
characters. Things like " and ' come over as if I were working in html
and have to be
edited back to normal text. It is an obvious correction so it causes
no trouble just a little time. If it it is easy for the software to
make the correction
that would be nice if not no big issue as the change is obvious."

Where have you noticed this happening?  In the downloaded text or CSV
files?  In the web pages?  Both?  This should be a simple fix.

If we limit the number of chars per line (there actually is a limit
but it's huge) how many should we limit them to?

I'll give the address issue some more thought and get back to you.

Aaron

On 5/14/10, Johnnie CD <johnniecd at gmail.com> wrote:
> Hello,
>
> For this application the system works well and it is certainly far better
> than anything I could come up with.
>
> I would find it most helpful it the city, province/region/whatever, and
> postal code were generally in the same field. It doesn't really matter what
> the field is called if the label on the form that the user fills out guides
> them to consistent entry it would be great. I realize some users will ignore
> it but I think some guidance might help. It only matters to me because I
> like to export the data from the system and import it into the application
> that I use to generate labels. Maybe you could alter the webpage text a
> little if it is complicated to change the guts of the program? Of course I
> don't know how it is setup I just offer my observations as an end user.
>
> You might even think about making 1 address, 1 city, and 1 postal code
> fields mandatory. We still get entries with no street address or no city.
> Undeliverable as such I suppose I could try to contact each of them but I
> did not do so for all of the old request.
>
> I would also find it helpful if the webpage form limited the number of
> characters in each field. Some folks enter strings to long that they will
> not fit on an envelope.  I does help to know where the logical breaks go in
> international addresses. This also would not matter for everyone that
> addresses their envelopes by hand but when exported long entries get
> truncated and the additional text has to be edited back in manually.
>
> The other interesting thing is the way the system handles special
> characters. Things like " and ' come over as if I were working in html and
> have to be edited back to normal text. It is an obvious correction so it
> causes no trouble just a little time. If it it is easy for the software to
> make the correction that would be nice if not no big issue as the change is
> obvious.
>
> Microsoft is driving me nuts with their email. They are prone to spam or
> junk anything sent from one email address claiming to be from another unless
> it is sent from inside their network. Of course their rules are not as
> clearly published as some of the other folks which makes it difficult to
> comply. If anyone know how to make them happy I hope they will share.
>
> I look forward to learning how other folks are using the software. Of course
> it would not make sense to propose any change unless it makes life easier
> for everyone and it requires only a reasonable amount of time to implement.
>
> Johnnie
>