Could users assign "nicknames" to their addresses, so that in the select box, instead of seeing their entire address listed across the box, they just see the nickname? (e.g. "Home", "Work"). Having the entire address in the select box can mess up the page at lower resolutions.

Right now I commented out lines 267-269 and 271-275 to show just the street name.

Thanks!

CommentFileSizeAuthor
#4 onceyouknowyounewegg.jpg69.83 KBgoodeit

Comments

freixas’s picture

freixas commented
Assigned: Unassigned » freixas

Seems like a reasonable idea. Don't suppose you'd care to do a patch? If not, could I interest you in writing a spec?

Should the nickname be required? If it's omitted, what happens? Should I ask for a nickname during registration or just assign "Default"? What if the user enters the same nickname for two addresses? What are all the forms and displays that need to be changed? Are there any pitfalls given that the order system won't know anything about these nicknames? Are there any other potential problems?

goodeit’s picture

goodeit commented

I'd love to write a patch... but I don't know enough about Drupal's settings pages, how to store data to mySQL or whatever, and how to look it back up. If you think this would be a simple endeavor and could point me in the right direction, I would look into it (but all your questions scare me enough into thinking its more complicated than it sounds).

At least I can try a spec (let me know what you think):
Users should be required to have a name for each address (the field should say something like "for example, 'home' or 'office'). If its omitted, it could either 1) throw an error and retry or 2) auto-generate from address line 1? During registration, the address entered can be stored as 'default', but changed later if desired. Nickname cannot be used twice (system will have to check for duplicates).

Forms/displays needed to be changed:

  • settings could stay the same
  • user/addresses: add "nickname" field display
  • user/addresses/(add & edit): add "nickname" field to top of form
  • cart/checkout: under delivery/billing info: change select lists to show nickname field

Potential problems include people with existing addresses which don't have nicknames. I would recommend generating from address line 1?

As far as I know, changing the display of the nicknames in the checkout panes does nothing (I have successfully changed it to display only Address 1 field). There is no reason that the order system, or anyone else, would need to know the nicknames.

hope this helps!

freixas’s picture

freixas commented

Re: the patch—can't blame me for trying! :-) Thanks for taking the time to propose a spec. It's nice to have someone else look at this.

Making the field required seems a little harsh and complicates the existing addresses problem. So how about making it optional? If it's missing, I create a substitute. Using the Address 1 field doesn't seem right. Occasionally, I have mailed things to different people at the same address. So, how about the name and Address1? Could you try this on your low-res system and see if that causes a problem?

About registration: I don't know why, but asking for the nickname at this point doesn't feel right. Maybe that's because I've never run into a system that requires this. Assigning the nickname "default" sounded good until I realized that there is always a "Default address" and that any address can be the default address. Naming one address "default" would encourage confusion if the default address was changed later. Always giving the default address the name "default" could wipe out a user's preferred nickname and leave an existing address without a nickname, so that's no good either. At this point, I would just omit the nickname during registration and treat it like any other unnamed address.

The empty string would be equivalent to not having a nickname, so the user could delete a nickname by editing the address.

Because missing nicknames are duplicates in the eyes of the database, the nickname field could not be relied on to uniquely locate each address. Therefore, duplicate nicknames aren't really a problem for the database, but they would cause confusion to the user, so the duplicate nickname check would have to be added (for non-empty nicknames).

As for the orders system, the only problem is for the poor administrator who goes into the order system to search for an order and slowly learns that the order addresses don't work like the uc_addresses. The lack of the nickname feature will just highlight the fact even more. Until uc_addresses is incorporated in Ubercart core, this separation will continue.

Anything I missed?

At this point, this doesn't seem like a difficult enhancement.

goodeit’s picture

goodeit commented
StatusFileSize
new onceyouknowyounewegg.jpg69.83 KB

Unfortunately. and I think it may be my theme, Even using Address1 field is a squeeze - depending on its length. For the record, I'm using a comfortable widescreen laptop myself... but I know many users are stuck in 800x600 land.

@default addresses: I would recommend keeping nicknaming/default selection separate, e.g. continue to use checkboxes to pick default. Then default would automatically show up on the checkout page filled in, but would easily be changeable. That way users could check/uncheck/move checks between addresses and not bother with changing the nickname. There would be no address named 'default' (but it could be bold or something?).

Attached is a screenshot of where I got my inspiration for this module (newegg.com). As you suggested, the "save as" (aka nickname) field is not required, but I tested it and if it was blank it was saved as "Address4" (that was my 4th address). That's a very unoriginal way to name things, but it does fit with the smushed resolutions. It also guarantees that each address has a nickname (and kind of encourages the user to rename them).

I'm not sure I understand the problem for the 'administrator' searching through the database. It seems to me that the nickname wouldn't mean anything to anyone except the user, who would only use it on the checkout page. All the administrator would see is the address, as usual, as if nicknames didn't exist. I dont think they (should) add any new information needed by the order system/admins.

Thanks for looking into this!

freixas’s picture

freixas commented

I'm not sure I understand the resolution problem. The width of the select field does not have to be equal to the width of the longest selection. I know, because this is how I handle the problem. I have a fixed-width design that fits on an 800x600 monitor. I have no problems displaying a full address, including name, street, city, state, zip. Obviously, some addresses are longer than others, but most people will see enough to make a determination, certainly more than just the street address.

The number of 800x600 users is dropping each year. thecounter.com reports about a 7% rate currently. The point is that I don't want necessarily want a lowest-common denominator solution and I'm not convinced it's necessary, at least not for 800x600.

Let me know if you can clarify the problem for me.

goodeit’s picture

goodeit commented

You're right. Changing the length of that field is not the only thing I had to do to get my content area to fit properly - in fact, there's no way of knowing if it needed to be done at all. I guess this started as a request for help fixing the issue with fitting it in and ended up being more of a feature request that has very little to do with the resolution problems I am having. I don't see adding a 'nickname' as a lowest common denominator fix - I see it as an enhancement for users of all resolutions (it's something I like to see when shopping).

Thanks again!

freixas’s picture

freixas commented

My comment about lowest-common denominator was not about the nickname approach as a whole, but the use of only the address1 field as the default for missing nicknames. Sorry about the confusion.

I'm still looking into adding this feature when I have a free moment.

Also, I thought about assigning some default name for any address for which the user does not assign a nickname, but I'd like this enhancement to be upwardly-compatible with the existing uc_addresses. Rather than trying to create default nicknames for existing addresses, I think it will be better to assign a value only on the checkout page for addresses with empty nicknames.

The shortest string I would use would be name + address1. But to be honest, I'd just as soon leave it using the current approach unless there's a real problem with resolution. This would create the least amount of change for existing uc_addresses users.

If you see a problem with this approach, let me know.

goodeit’s picture

goodeit commented

@ the lowest common denominator: My mistake. I see nothing wrong with your way of doing it, making the nickname optional and then displaying the full address if none is entered.

I also don't see a compelling problem with resolution - if there is a problem specifically with my theme at 800x600 I can simply change the module as I have already.

Thank you for your discussion and work!

freixas’s picture

freixas commented

OK, I've added the feature and did some testing. There could still be problems. Could you try this out and see if you can find any problems? Let me know whether you find any problems or not—either bugs or usability problems.

You will need to either check this out from CVS or wait for the dev build to be updated (check the date on the build).

Important: you need to run update.php to add the new field 'address_name' to the database.

freixas’s picture

freixas commented
Status: Active » Fixed
goodeit’s picture

goodeit commented

freixas, finally got a chance to upgrade to 2.0rc2... The nickname feature works great! Thanks so much!

freixas’s picture

freixas commented

Thanks!

Please keep an eye out for an error message saying that the nickname is already in the database when it really isn't. I saw this show up once and then wasn't able to reproduce it. If you do run into it and can characterize the circumstances that cause it to appear, that would be great.

I'll be looking as well. I would like to believe all is working fine, but I'm not sure I'm completely there.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.

lambarona’s picture

lambarona commented
Issue summary: View changes

How to get Remark (The nickname for this address)?

educationfresh.com