输入邮寄/财产地址的最佳方式?

发布于 2024-08-02 10:29:33 字数 840 浏览 7 评论 0原文

我正在寻找有关在网站上输入财产地址(即房屋或企业地址,而不是电子邮件地址)的两种不同方式的想法。单独的字段与单个灵活的多行输入字段相比有何优缺点?或者具有单独的邮政编码条目的多行?

大多数站点使用单独的字段,并且可能将这些字段存储到数据库中的单独字段中。换句话说,输入通常是以下内容的某种变体:

House:       [input field]
Street 1:    [input field]
Street 2:    [input field]
Town:        [input field]
District:    [input field]
Postal code: [input field]

但是,对于快速打字员来说,输入上述内容有点笨拙,并且在具有更自由格式地址的地方也有点限制。如果您必须“插入”或“删除”一行,则编辑起来会很麻烦,因为您必须向上或向下复制每个字段,或者重新输入整个内容可能会更快。

另一种选择是自由格式的多行输入(带有可选的滚动条):

Address:     |multi-line input field|
             |                      |
             |                      |
             |                      |
             |                      |
Postal code: [input field]

如何存储地址?如果是多行,请将所有行存储在单个数据库字段中?或者在编辑时分成单独的字段并重新组合成多行字符串?

如果拆分字段,您使用哪些字段以及它们的宽度是多少?

I'm looking for thoughts on two different ways of entering a property address (i.e. the address of house or business, not an e-mail address) on a web site. What are the pros and cons of separate fields versus a single flexible multi-line entry field? Or multi-line with a separate postal code entry?

Most sites use separate fields and, presumably, store these into separate fields in a database. In other words, input is often some variation of:

House:       [input field]
Street 1:    [input field]
Street 2:    [input field]
Town:        [input field]
District:    [input field]
Postal code: [input field]

However, the above is a bit clunky to enter for fast typists and it's also a bit restrictive in places that have a more free-form address. It's fiddly to edit if you have to "insert" or "delete" a line because you have to copy every field up or down, or retyping the whole thing may be faster.

An alternative is a free format multi-line input (with optional scrollbar):

Address:     |multi-line input field|
             |                      |
             |                      |
             |                      |
             |                      |
Postal code: [input field]

And how to store the address? If multi-line, store all the lines in a single database field? Or split into separate fields and recombine into a multi-line string when editing?

If split fields, what are the fields you use and what are their widths?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

温柔嚣张 2024-08-09 10:29:33

我会选择一个多行输入字段。不同国家/地区的地址格式不同,并且具有不同的组成部分:例如,许多国家/地区没有州(表示为 N/A)。邮政编码可以是 5 或 9 位数字,也可以是 2 组,每组 3 个字母数字等,因此考虑到这一点可能会很复杂。

但是每个人都可以在给定的多行文本框中以自然的形式输入他们的地址。

I would choose a single multi-line input field. Addresses in different countries are formatted differently and have different components: for example, there's no State in many countries (expressed as N/A). The ZIP code may be 5 or 9 digits, or can be 2 groups of 3 alphanumerics, etc., so taking that into account can be complex.

But everyone can enter their address in a natural form given a multiline textbox.

断念 2024-08-09 10:29:33

我更喜欢使用单独的字段,因为这会产生结构化信息,而单个字段给出地址但结构未知。明显的优点是单个字段允许输入与预期格式不匹配的地址 - 例如国外地址和邮政信箱。

在思考你的问题时,我得到了以下想法 - 混合解决方案。有一个输入字段,但是当用户键入时,输入会被分析和分割,并且该分析结果会显示给用户 - 微妙地突出显示旁边的字段名称,类似于工具提示。对于不同的地址类型和国家/地区,您可以采用不同的格式。分析可以基于地址的整体结构,也可以基于州、国家的名称或邮政编码的格式。正则表达式可以做到这一点,但也可以考虑自定义描述格式。也许 XSD、XML 或类似的描述语言也可以被(滥用)使用。

用户应该能够通过上下文菜单或类似的方式从列表中选择格式来更改格式,更改尚未正确分析的单个字段,甚至完全重新标记整个地址。这将成为一个相当复杂的控件,我不确定第一次看到它的用户能够如何处理这个控件。例如,我可以想象用户会很想立即更改未正确检测到的字段,而不是等到他们完成输入后正确分析地址的机会比第一行之后更好。

I prefer to use separate fields because this yields structured information while a single fields gives the address but with unknown structure. The obvious advantage is that a single field allows to enter addresses not matching the expected format - for example foreign addresses and post office boxes.

While thinking about your question I got the following idea - a hybrid solution. There is a single input field, but while the user types the input is analyzed and split and this analysis result it shown to the user - subtle highlighting with the field name next to it, something similar to a tool tip. You can have different formats for different address types and countries. The analysis could be based on the overall structure of the address but also on the name of states, countries, or the format of postal codes. Regular expressions could do that but one could also consider a custom description format. Maybe XSD, XML or similar description languages could be (ab)used, too.

The user should be able to change the format by selecting it from a list via a context menu or something like that, change single fields that have not been correctly analyzed, or even completely re-tag the whole address. This would become quite a complex control and I am not sure how well user seeing this for the first time could deal with this control. I could for example imagine that user would be tempted to change not correctly detected fields immediately and not wait until they finished typing a chances for correctly analyzing the address are better then after the first line.

快乐很简单 2024-08-09 10:29:33

我更喜欢分割字段,因为这样分割的内容就很明显了,而且它还可以帮助以前在表单保护程序类型应用程序中输入信息的人。快速打字员知道按“tab”键在字段之间导航。

在这两种情况下,您都需要以“已解析”的形式存储地址,因为您可能需要用它来做一些事情。 (检查郊区等)。

I prefer the split fields, because then it is trivially obvious what the breakup is, and it will also help people who have previously entered information into form-saver type apps. A fast typist knows to press 'tab' to navigate between fields.

In both cases you need to store the address in a 'parsed' form, because you may need to do things with it. (Check the suburb, etc).

烛影斜 2024-08-09 10:29:33

我会选择单独的地址字段。这是能够进行任何类型验证的唯一方法。

目前我遇到的问题是,即使在上面指出的单独字段中,我也没有正确的方法来检查门牌号是否已填写。

(在我的国家,例如对于运输东西来说,这有点重要)

I would choose separate address fields. It's the only way to be able to do any kind of validation.

Currently I'm having the issue that, even in the separate fields indicated above, there's no proper way for me to check if a housenumber is filled out.

(which in my country, for shipping stuff for example, is kinda important)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文