contacts
contacts copied to clipboard
owncloud
OC9 - for what purpose has a separate letter box field added?
Expected behavior
Only necessary address book fields should be shown by default. Unrequired
fields should be suppressed, like e.g. the letter box field.
Current behavior
When selecting an address book entry a new letter box field is shown on top of
an address book record which usually is empty. Unfortunately I don't have a clue
for what purpose this field has been added, because only big companies might
own a separate letter box beside a street address but in a private environment a
letter box is seldomly used.
Additionally letter box should better be translated as Postfach instead of
Briefkasten in German language.
Environment
Server Configuration
OS: Linux 3.2.75 Web server: Apache2 2.4.18 Database: MariaDB 5.5.46 PHP version: 5.6.17 ownCloud version: 9.0.0 Calendar app version: 1.0.0 (20160320) Updated from OC8.2.2
Client Configuration
Browser: Firefox 45.0.1 Operating system: Windows 7
@jancborchardt Do we want to suppress that field by default and make optional?
This is yet another example of bad translation :angry: this is the post office box - known in Germany as Postfach - a quite common required field.
Do we want to suppress that field by default and make optional?
How shall we do this? Add a button to display this field? I don't think we get much out of this.
The point of @j-ed is still true:
only big companies might own a separate letter box beside a street address but in a private environment a letter box is seldomly used.
And I also told you I wasn't happy with the introduction of that field. ;)
Did you check out how the previous contacts app handled address input? One field, with the ability to expand to modify the details. Can we do it like that? Cause e.g. Android contacts does it similar, and it's much simpler than an ugly form field list.
The old contacts app had a concept where view Mode and edit Mode are different. We don't have that by now. Once we have that this issue will resolve by itself. But I see a ton of more important issues by now. Id like to get 1.1 out asap
That’s unrelated though. I was saying that ideally the input/edit function of the address is only one field. And you put in addresses comma-separated like one usually does. And the app parses it using some address resolver or whatnot. Then when you want to edit some additional details, you could expand the fields to the more complicated display.
TL;DR yes I know this is hard, but much like name input, no one wants to put in first and last name separately. It’s just a damn pain to have so many form fields so we should aim to reduce them. We’re also not requiring people to put in email address username and server separately, do we? ;D
That’s unrelated though. I was saying that ideally the input/edit function of the address is only one field. And you put in addresses comma-separated like one usually does. And the app parses it using some address resolver or whatnot. Then when you want to edit some additional details, you could expand the fields to the more complicated display.
This is even more painful - the comma separated parts have an explicit meaning and we don't want people to type in technical data.
The correct format is specified here https://tools.ietf.org/html/rfc6350#section-6.3.1
Applying some magic parsing in contrary will just blow it up.
Hello,
The point of @j-ed is still true:
only big companies might own a separate letter box beside a street address but in a private environment a letter box is seldomly used.
I beg to differ. PO Boxes are not that rare event for private people (especially if self-employed). Around here (France), we do have contacts with street address + PO Box or PO Box only. It would be nice to keep this in OC.
We mainly need to adjust the layout so the look is simplified. It should be something like:
[ Street ] [ PO Box ]
[ City ] [ Postcode ]
[ Country ] [ Region ]
(Intentionally that way so that the left column lists the most important info.) What do you think?
Wouldn't it be easier to handle PO box addresses separately from normal addresses, like entering a new address because it isn't only the PO box number which might change but also the zip code and city. Currently it is differenciated between Private, Work and Other. By adding a new category PO Box we would get the whole flexibility to enter a PO box number, a new zip code etc. In addition this would also simplify the address display. Concerning the fields which are displayed, let me mention that in many countries, like Germany, the zip code is written in front of the city and not behind it and house numbers are written behind the street name and not in front of it. Regions are normally not required and used.
Therefore I would aspect the following layout for normal address data:
[ Street name] [ House number ]
[ZIP code ] [City]
[Country ] [ Region ]
This could be the layout for PO box data:
[ PO Box ]
[ZIP code ] [City]
[Country ] [ Region ]
It might be worse to have a look on the following web page, which describes how SAP handles address and PO box data and which fields are used: https://help.sap.com/saphelp_erp60_sp/helpdata/de/18/c042eada4811d3b571006094192fe3/content.htm
@j-ed yes, as I said:
Intentionally that way so that the left column lists the most important info.
But if we aim to make it work for most nations, let’s just go with this standard layout:
[ Street+Number ] [ PO Box ]
[ Postcode ] [ City ]
[ Country ] [ Region ]
Reasoning:
- Street+number is one of the most important things. PO Box is optional for when it’s needed, or like a
c/o - Postcode is before city because that’s often done like that as @j-ed said
(We should not separate Street and house number – not even more input fields please …)
@jancborchardt I understand. What do you think about adding a new address category PO Box instead of mingling street address and PO Box data. As I wrote, in Germany a PO Box is normally not located at the same address as a company/person reside and also may have a different zip code and city.
This would also allow to use the same field for the street address and PO box without the need to add additional fields.
What do you think about adding a new address category PO Box instead of mingling street address and PO Box data
Great point actually, why didn’t we think about that. :D It makes stuff a bit more complicated for when you do need a PO Box, but we could actually query the region format and for regions where a PO Box is used add it as automatic field.
@Henni @irgendwie @DeepDiver1975 what do you think about that?
but we could actually query the region format and for regions where a PO Box is used add it as automatic field.
@jancborchardt such thing exists? Please ref a special or service which could help us with this respect. THX
@DeepDiver1975 actually scratch that – it’s not dependent on the region of the user of course, but you could have contacts all over the place which might or might not have PO boxes.
In the UI we should have it as a separate entry for now, as was said above.
IMO, the purpose of the Contacts app is to store, display and exchange vcard data, so RFC 6350 has to be the definitive standard, which says that the fields are:
- the post office box;
- the extended address (e.g., apartment or suite number);
- the street address;
- the locality (e.g., city);
- the region (e.g., state or province);
- the postal code;
- the country name.
Therefore, those fields must be presented in Contacts – nothing less. (Of course, there are not enough fields there to satisfy many national postal address schemes, but that is not your problem.) Extra information can always go in the Notes field, if it's essential.
There are 192 member countries of the Universal Postal Union, each specifying the correct format for postal addresses in its respective territory. Getting [ownC|Nextc]loud] to show these correctly is not a trivial task. Just within Western Europe, there are at least half a dozen 'standards', to my knowledge, so picking any one is also hopeless (afaik, the German format is unique to Germany, so would be wrong everywhere else ...). So, it's not even worth spending time on this, imo.
It is the job of others (users, software, whatever) to format the address for the postal label. Please keep function as the priority. When it works perfectly, then make it look pretty. Stop worrying about the staff bike-shed.
@hameau Since this is the second time someone brings up »bikeshedding« when we were talking about how to design stuff well, I’ll just make it clear:
One of the main goals of this software project is that it’s easy to use, not just barely functioning. Traditionally open source software hasn’t put a lot of weight on good design, but we and lots of other projects nowadays do. The fact that it’s open source does not mean we can’t do a great product.
Design is not just »making it pretty« nor is it a triviality to be tacked on at the end. It’s involved since the very beginning. If it wouldn’t then the software wouldn’t work and look like it does now and frankly might not be as popular and you might not know about it and leave this comment here right now.
So please don’t treat design as if it’s just a layer on top of the code.
@jancborchardt
If it wouldn’t then the software wouldn’t work and look like it does now and frankly might not be as popular ...
Well, frankly I don't think the Contacts app works as well as it used to. Just to cherry-pick a couple of issues:
- How on earth did those colours get through to release (v1.3.1.0)(https://github.com/owncloud/contacts/issues/432)? White letters on bright green or bright yellow? I can't even read the name of the contact without changing the css locally. (I know that #432 has been closed and merged, but it is not available in the production version.) And that discourse on the best way to generate random colours (#300)? That really is bike-shedding. Even an ownCloud member questioned its importance.
- one click to permanently delete a contact, with no confirmation, no back-up and no undo? Surely a serious regression, but tagged 'Enhancement' and with a milestone of 2.0 (https://github.com/owncloud/contacts/issues/201). I don't care what the design team thinks, I want buttons for 'Edit', 'Save' and 'Cancel' and a confirmation for 'Delete'. I want to be able to delete a field contents only when in Edit mode.
One of the main goals of this software project is that it’s easy to use, not just barely functioning.
At the moment, it's not easy to use and still only barely functioning, imo. I'm all for elegant design and I agree that it is not something to be added at the end, but it cannot be at the expense of core function. I came here to see if the colour problem had been reported and I couldn't believe how much effort was being poured into stuff that isn't important 'right now'.
Regarding this issue report, it is apparent that commenters have no understanding of the RFC requirements and are discussing things that are immutable for the Contacts app's core function.
By the way, where is the other mention of bike-shedding? I'd like to give it a +1.
Gentlemen - instead of blaming and throwing shit at each other - please just contribute and fix things.
Agree with @j-ed about adding Post Office Box as a different address type (like home, work, postal, location, other) since it is indeed a different address type (it's not a physical address per se).
Having addresses parsed (as per @jancborchardt ) is a nice idea, but unworkable given the number of global and regional address connotations, and that Users tend not to be very consistent in the way they enter data. Having a limited number of well-known fields with an 'expand' arrow or +sign would be more useful (to expose other fields), that's what other software does that Users are now well-used to - e.g. smartphone and webmail interfaces.
Moreover, #462 would ensure that the address layout shows the User's default national layout, and when the User enters a different country, the layout would change. Maintenance would be minimal - the data that @hameau points out in international addressing standards barely changes.
There's no sufficient reason not to make this app it easy for the User, elegant, standardised, and compatible with vCard 4 standards simultaneously.
Finally, the view/edit mode would make the layout and appearance a lot easier #459 - as @DeepDiver1975 mentioned. It would mean unused fields disappear, the interface is more elegant and less confusing. Most usage of contacts apps is for viewing not entering data.
It's important to think globally and 'outside the box' (pun intended) and make software accessible to users. A Post Office Box is important for personal users, not just corporate customers. They provide the only means of delivery for over 1 billion people in the world who are not offered delivery to the door - including most people in Africa (for example Kenya, Namibia, rural Nigeria), Jordan, parts of Asia, and many remote communities in USA and Europe. Also, personal customer or small business Users still send mail to corporate addresses, indeed in the UK it's most common form of mailing. To keep things simple, but comprehensive, both #462 and 'post box' type addresses are advocated.
@olantrust we do not want to introduce a separate read/edit mode since it’s an unnecessary distinction. If at all, we could make the items appear as if they are read-only (remove the border around the text fields) and have them appear on hover, and editable on click. Basically like we do for the name/lastname input.
But to simply keep it to this issue: the solution by @j-ed to add post box as a separate field is best. Now someone just needs to step forward and implement it. ;)
we do not want to introduce a separate read/edit mode since it’s an unnecessary distinction.
I feel most strongly about this decision. It is too easy to make irrevocable changes to live Contacts data, completely without warning.
There is a good reason why a workflow of 'Select edit', 'Make changes' then 'Okay/Accept/Save' or 'Cancel' is the accepted norm. Please, let's have 'Least surprise': wiping out Contact data without warning is not it.
There is too much discussion in this issue. It is not clear how this shall work.
Please join https://central.owncloud.org for discussion on how this shall work.
Based on any decission we come back to github with an explicit list of Tasks.
Closing ..
Reopening and locking since there is indeed an explicit task as said multiple times above:
- [ ] change the post box to a separate field which has to be added via the dropdown and is not there by default.
No need to discuss further on a forum which is separate from this repo. Also, anything discussed in this issue which has nothing to do with this issue should be opened as a separate issue.
@DeepDiver1975 please explain. Can’t find why it shouldn’t work in previous comments of yours on this issue.
When the value of post box is found in the vCard of course the field is shown. If not it’s just not there. I really don’t see the problem with that approach since we’re just fixing it in the frontend.
There is only one field in the vcard: address. We either add an address or we don't. There is no separate Po Box field