I'm trying to develop an easy way for users to enter addresses.
I've got a database of postal codes and cities already, so if a user enters his street address and postal code, I can (usually) retrieve the city, province, and country automatically. However, if this information is missing from my database, they'll be required to fill it in.
I'm trying to decide what this should look like. Should I just display the 2 fields (street and postal code) by default, and then after they've filled it out, use AJAX to validate the postal code, and if it's not found, make the rest of the fields appear? This has the drawback that they may be part way through the rest of the form before it appears.
I could take the opposite approach and hide the extra fields only if the postal code is found. But then they might fill out information they didn't need to by the time its validated. Or is there some middle ground?
Just trying to figure out the quickest and easiest/user-friendly way for people to enter addresses. Suggestions?
I've done this before. I had the user enter street and zip code, then they had to choose what city they were from in case there was more than one to choose from. I didn't hide any fields, but there wasn't anything to choose from until the postal code was validated via AJAX. It seemed to work quite well not hiding anything.
However, between the two options that you mentioned, I would go with the first one. That one is closest to what has worked for me.
i'd say try to implement something like predictive search which takes both, city an zip field, as search params.
for example you've typed your zip code, click (or tab) to the city field, you get a list of cities where this postal code applies.
but don't force the user to take one of the entries in the list.
with that you can auto-populate your database if the user's city isn't already in it.
that's something i'd like to have :)
Addresses are usually "value objects" meaning they are read only to an entity (such as a customer), which means you should probably let them pick out an existing address or create a new address.
That said, this also depends on your target audience. Are they good at entering addresses? For example, I always throw up a pop-up control for dates so there isn't a chance they would pick an invalid date.
You could look at how Navigation systems work. They always ask for a destination. Mine does an auto complete on the street first, then house number, then city / zip. Just look at the more popular units.
just disable the extra fields while they fill in their lookup information. You AJAX calls shouldn't be that slow. If they are then you have some serious problems to address other than this.
But you are on the right path.
I would start by having them enter just the Postal Code, and I'd probably submit the form and return two different forms depending on whether or not you have the available data in your database.
One word of warning: people can get extremely sensitive about vanity addresses. Your database probably says that 94027 is Redwood Shores, CA, but if you tell someone who thinks that he live in Atherton that he lives in Redwood City, he's going to get pissed. Sometimes, it is better not to do extra work when people are entering address information.
Related
I'm using Flask-Mail to send email notifications for events and currently I'm encountering a problem where if two emails of the same subject end with the same thing (which is a rather niche circumstance, but definitely necessary to consider nonetheless), the ending part of the second email will be collapsed by certain mail clients (gmail, for example) that think it's a sign-off or signature or whatever. How do I prevent this?
Currently what I'm doing is generating a random sequence of letters and putting it in a <span style="display:none">...</span> and appending that to the email so the client thinks it's a different footer, but that feels really hacky and I want to know if there's a proper way to do it.
After doing some research, it does not seem as though gmail gives you an option to turn this off. All of the articles written on this topic suggest making your footer unique, which is exactly what you are doing.
Furthermore, this option means that the content of the email does not change at all. This seems to be the best solution.
There is an option in Gmail which allows you to turn off conversation view.
How the grouping occurs is:
The subject must be similar
The sender must be a part of the thread OR in-reply-to must be used
Now to save space, Gmail condenses texts that are same, which is what you see. If you want to turn off conversation view in desktops just navigate to setting -- > generals (tab) for desktop and use the radio button select and press save.
If you are after other devices check this link out.
I'm developing a dropbox app (accessing a Dropbox for Business account). I need to pass along a custom header, X-Dropbox-Perform-As-Member, which has it's value set to a member ID (or member_id).
For the life of me I can't seem to figure out where to find or retrieve this specific value. Hell, I don't even know what it looks like ...
Anyone care to point me in the right direction? Thanks in advance.
There are a few places the member ID might come from... it depends a lot on the kind of app you're building. One likely source is a call to /members/list. Another likely source is /members/get_info (if you're looking up by email address).
For an auditing app that's watching activity within a Dropbox for Business account, you'll find the member_id as a member of lots of events in the audit log (i.e. via /log/get_events).
I've always assumed that it's risky to identify users in urls within emails. For example, let's say my app is something like eventBrite. I'm inviting a set of users to an upcoming event. I create unique urls for each user's email which allows them to simply click those url's in the email to accept or decline. Ie, they will not have to authenticate with the website.
If they view the email on a mobile device or a public computer through webmail, then clicking the links will fully accept/decline.
Is this approach too risky? I had assumed you should avoid this as something could see those urls and make requests on them which would trigger false accepts/declines.
It'a an opinion but I would assume the link itself can be more secure than the email actually. You can make the accept link valid only through certain period of time (it would not make much sense otherwise anyways).
Moreover, you can make it pretty much arbitrary long. So it's basically arbitrarily hard to guess.
That would leave two options to "see" the link, that I can think of. Physically seeing it by eaves dropping. But you could generate a mail in the html form, which would allow you to hide the full link behind a hyper-ref text. Like Accept / Decline.
There are several parts to this answer:
Is it secure? Absolutely not. It's security through obscurity. You're betting somebody can't guess the link which, as long as it's a finite string then they totally can and as soon as they do, they can RSVP to your event.
Follow up Does it matter? Probably not. I imagine the chances of somebody trying to spoof an RSVP to an event are pretty slim. I absolutely wouldn't protect anything critical this way but if you're just doing something like event RSVP etc (no money changing hands) I don't see anything wrong with this approach. As luk32 said, you can also make the links valid for limited amounts of time etc.
The real issue here, (unless there's something you're not telling us and this is somehow a high value target) is how likely is somebody to accidentally stumble on one of these links and RSVP to an event they aren't going to? You can make the chances of that exceedingly unlikely by generating the links in a sufficiently random manner so that no two links are a like. In this case, I don't think security is the big concern so much as data integrity. That is, is the data you're receiving valid.
We're programming a Testing Web Application for a University in ColdFusion with a MS SQL Backend.
Right now we have to manually take faxes sent to our fax machine and then find the account they are related to and input the info (the actual fax has to be found in a filing cabinet if we ever need to reference it again). What I would like to do is create a way for someone to fax to a certain number and then the fax be sent to an email account we specify.
If that worked properly we would need a way to get the email, store it somewhere on our servers and then link it to an account. The linking process would probably have to be manual and we are ok with that, but an easy way to view all the faxes sent to that email in our ColdFusion application in PDF form (searchable by the name we assign it) is what we are mainly looking for, so that we don't have to get the faxes on paper and file them by hand.
Is there a way to accomplish this? Preferably not through a paid service as we can program almost anything we need ourselves.
Hmm... have you tried services like eFax?
Why reinvent the wheel? Services like eFax and jConnect (there are several others, just Google "electronic fax service") are affordable and do half of what you are trying to do. Save yourself the effort and just spend a few bucks. You'll probably find out, too, that it will cost you less to just pay for the service than it would cost you to pay the developer to write the software.
So after you bite the bullet and sign up for an electronic faxing service, you just need an email account for it to send to, and to use CFPOP to check the inbox and download the attachments. The rest is a piece of cake.
From the sounds of it, I have built something identical to this faxing setup with Coldfusion.
After a few trials and errors I found best way to go is:
1) DIGITIZE INCOMING FAXES: Have all faxes either sent to an email address you can check via CF, or a network folder you save them on, which you can check with CF. You can absolutely keep your fax number and simply call forward incoming calls to your digital fax number.
2) PROCESS INCOMING FAXES When you find a new fax, it is best to process it and make a record of it. I store things like the file name, dig up the fax number it came from, check it against a list of known numbers, and have a routing table (in case it needs to go to someone).
3) PRINT AND ROUTE FAX Auto printing a document once in CF is possible via CF as well.
As for tables, I keep one to store each fax. I store the fax itself in a blob as well. Easy to replicate and move around, no big performance hit. I keep another table to store a list of incoming number profiles (like a caller ID table) to relate the number to a customer. I keep a table for routing rules, if an email comes from here, send it here. Last, but not least, if you have to manage multiple phone numbers, you can create multiple incoming profiles and file them.
Once you have each fax stored in the DB, you can do a lot with it and file/index/ store it digitally how you like. CFDOCUMENT will display disk based PDFs.
I ended up having to program something like this for custom routing options. It is possible to auto link items to certain files/folders/projects if you like as well with CF.
If you need to know anything else, ask, or we can discuss it off line if you need to keep some details private.
Agree with Adam. Don't create a bunch of problems for yourself - you'll save a lot of money and nerves by just using the existing service.
On the topic: I use Popfax and I kind of like it. It's comfy, gives you opportunities, discounts, contests and a lot of stuff you'd like if you'd be interested in. It's cheap (at least, 100% cheaper than your own software) and you can use it not only on PC, but also via mobile phone
My current app needs to store address information for a user. I'm currently debating whether to use the customary street address / city / state / zip textboxes and dropdowns or to go with Google's method of simply having everything on one line. Any thoughts on the pros/cons of storing address information in either of these manners?
You should split it up. It will make it far easier to do reporting down the road. What happens if you want to pull up all the residents of a state or zip code, or city? If you use all one field, you will be stuck and wish you had split it up.
Also, users will forget to put in all the information you need if you don't prompt them for it.
Judging by the user-input tag on your post, I assume you are referring to how the user enters the data, and now how you are storing the data in your back-end database.
Presumably your database will still need to store this information as separate fields, if you want to be able to sort and analyse the information (e.g. for reporting and statistics purposes).
In this case, I think it would depend on how confident you are that you could parse the addressing information properly into its individual fields.
One hybrid option would be to allow the user to enter the address as a single line, and then do a best-effort parsing of the information into the separate fields. This is similar to how Outlook manages addresses for contacts - you enter all of the information into a single memo field, and then it splits it up for you. You can then correct if it interpreted any of the fields wrong.
I would be very much against just having a single text field where users enter their address. You'd be surprised how many people will leave out their zip code or some other important info if you don't have a specific field for it. Also, as others have mentioned, it make reporting much easier to report on this information later if all the data is pre-parsed. As other users mentioned, programs like outlook will parse this information, but only because the source of the data is often the signatures of emails, which is something that is never in a consistent format.
I tend to split it up, allows searching to be done for a specific section of the address and you can limit the addresses you want to handle by knowing the formatting i.e. Only ship to east coast addresses.
1) You should split it.
2) May I recommend you read this before you attempt to do international address input?
I concur with Kibbee. I was even surprised to see people don't even read the field's labels, inverting first and last name, postal code and city, etc.
No, you can't determinate if a postal code is valid, in a Web application targeting international customers...
Some countries have alpha characters in postal code, various lengths, no state info, etc.
Definitely split the input. If you can help it--and depending upon your business requirements--it may be wise to perform address verification at the point of entry. This will allow you to know that your addresses are going into your database clean and allow you to do a number of other things such as fraud prevention. Having a verified address can help reduce shipping costs if you're shipping physical goods to your customers and can help reduce credit card merchant fees by ensuring the correct ZIP Code is submitted during AVS verification.
In the interest of full disclosure, I'm the founder of SmartyStreets. We offer CASS-certified address verification services. Users can upload a list for scrubbing (CSV/Excel/etc) to our website or use our address verification web service API called LiveAddress.