Do we, as developers, have a UI responsibility?
-
The way american Papuan speaks has nothing common with how it should be written. If you see time "10 hours 12 minutes", IT IS NOT "thousand twelve", whatever military people say. Feel the difference? Same with dates, especially when only crazy USA has clumsy order "month day year". Normal order is "day month year". Day number is more important than year. And if you exchange dates with other people, think twice before you force 'em to scratch head with your "17/7/17". Universal date is quite simple: "dd MMM yyyy". No mistakes, no fighting, suits for much more people than living in america.
Your time example actually proves my point more than yours. The format you like: dd/mm/yyyy is in decreasing significance order, meaning most specific to least specific. So if you were to extend that with time then it would be ss:mm:hh dd/mm/yyyy. But I am sure that seems ridiculous to you. We all use cultural rules when choosing how to display data. Do you also insist that in languages that are read from right-to-left that they should switch to left-to-right because you feel it suits more people? If you were designing a UI with a status indicator and you chose a fairly standard red/yellow/green scheme would you refuse to change it after finding out your users were colorblind because the scheme suits more people? The point is that it is how your users feel about the way data is presented that matters. That is a higher responsibility than adherence to rules you feel are "universal".
-
Your time example actually proves my point more than yours. The format you like: dd/mm/yyyy is in decreasing significance order, meaning most specific to least specific. So if you were to extend that with time then it would be ss:mm:hh dd/mm/yyyy. But I am sure that seems ridiculous to you. We all use cultural rules when choosing how to display data. Do you also insist that in languages that are read from right-to-left that they should switch to left-to-right because you feel it suits more people? If you were designing a UI with a status indicator and you chose a fairly standard red/yellow/green scheme would you refuse to change it after finding out your users were colorblind because the scheme suits more people? The point is that it is how your users feel about the way data is presented that matters. That is a higher responsibility than adherence to rules you feel are "universal".
-
I'm going through expenses, and for anyone living in Canada who doesn't have that weird Canada / US hardware translation unit built into their brain, it's painful. It's the dates. The US, alone, uses mm/dd/yy. The rest of the world except for Belize uses something vaguely sensible. Even Canada. Except Canada has a ton of systems imported directly from the US (or shares systems with their US parent companies) so lots of dates on things like receipts are in the form mm/dd/yy. Or they are dd/mm/yy. You can't tell. 06/07/17. Guess the date. Canadians can tell, just by looking at the date whether it's June or July. To me that's impossible yet they seem to do it. Somewhere a programmer decided to output the date this way. Either they just used the default date formatter or they deliberately choose a dd/mm/yy or mm/dd/yy format. 5 seconds of work would enable them to output in dd-MMM-yyyy or dd-MMM-yy or even yyyy-mm-dd or yy-mm-dd format. Either of which would allow a high level of accuracy in guessing the date. I'm sure they also thought, at the time, that their decision was a valid one. It wasn't, and it made me wonder whether we as developers have a responsibility to ensure that the information we present to the world is always presented unambiguously. Is this something you do? Is it something your lead actually stops you doing? Or is it something you've not really though of?
cheers Chris Maunder
Well, it always helps to have empathy towards the end-user in order to achieve as much ergonomic and intuitive programs, but back to your case, the programmer in charge of redacting the database transaction layer is supposed to make sure that the date is stored using a time-stamp, whereas the UI programmer should take care of accordingly parsing this time-stamp on an end-user localization basis so that the end-user can for example always remotely generate a consistent receipt whatever his location. But yes, both programmers can definitely be the same person. Presenting information to the world in various notations or languages require more UI efforts than using more standardized schemes, but have its charms. In all cases, if the data is presented ambiguously, then the project is an epic failure (!?), with data dumped to the end-user becoming inconsistent so unusable, but in theory and back to your initial question, inside a project with respective road-maps for several programmers, it would be the UI programmer's job to properly dump / format data that have been consistently stored.
Kaveh Rassoulzadegan
-
You prove yourself the way you like, but nothing meaningful to me. If some doc needs timestamp, it's quite easy: "17 Feb 2017 15:27" - format understandable by all humans in the world. Everything else you wrote - TL;DR
Yes that works just fine unless they speak only Russian, or Chinese (which accounts for quite a large number of the humans in the world). The fact that you TLDR for a single paragraph means you have no interest in learning anything and are willing to stay ignorant. Good luck with that.
-
I'm going through expenses, and for anyone living in Canada who doesn't have that weird Canada / US hardware translation unit built into their brain, it's painful. It's the dates. The US, alone, uses mm/dd/yy. The rest of the world except for Belize uses something vaguely sensible. Even Canada. Except Canada has a ton of systems imported directly from the US (or shares systems with their US parent companies) so lots of dates on things like receipts are in the form mm/dd/yy. Or they are dd/mm/yy. You can't tell. 06/07/17. Guess the date. Canadians can tell, just by looking at the date whether it's June or July. To me that's impossible yet they seem to do it. Somewhere a programmer decided to output the date this way. Either they just used the default date formatter or they deliberately choose a dd/mm/yy or mm/dd/yy format. 5 seconds of work would enable them to output in dd-MMM-yyyy or dd-MMM-yy or even yyyy-mm-dd or yy-mm-dd format. Either of which would allow a high level of accuracy in guessing the date. I'm sure they also thought, at the time, that their decision was a valid one. It wasn't, and it made me wonder whether we as developers have a responsibility to ensure that the information we present to the world is always presented unambiguously. Is this something you do? Is it something your lead actually stops you doing? Or is it something you've not really though of?
cheers Chris Maunder
This why we hire developers and designers. And, FWIW: 20170809 FTW
-
I'm going through expenses, and for anyone living in Canada who doesn't have that weird Canada / US hardware translation unit built into their brain, it's painful. It's the dates. The US, alone, uses mm/dd/yy. The rest of the world except for Belize uses something vaguely sensible. Even Canada. Except Canada has a ton of systems imported directly from the US (or shares systems with their US parent companies) so lots of dates on things like receipts are in the form mm/dd/yy. Or they are dd/mm/yy. You can't tell. 06/07/17. Guess the date. Canadians can tell, just by looking at the date whether it's June or July. To me that's impossible yet they seem to do it. Somewhere a programmer decided to output the date this way. Either they just used the default date formatter or they deliberately choose a dd/mm/yy or mm/dd/yy format. 5 seconds of work would enable them to output in dd-MMM-yyyy or dd-MMM-yy or even yyyy-mm-dd or yy-mm-dd format. Either of which would allow a high level of accuracy in guessing the date. I'm sure they also thought, at the time, that their decision was a valid one. It wasn't, and it made me wonder whether we as developers have a responsibility to ensure that the information we present to the world is always presented unambiguously. Is this something you do? Is it something your lead actually stops you doing? Or is it something you've not really though of?
cheers Chris Maunder
Developers have a responsibility to understand the system that they are building, and preferably before they start building the system IMHO. How the system is intended to be used (via a User Interface), and by whom, is part of that understanding. Therefore the answer has to be 'Yes'.
-
I'm going through expenses, and for anyone living in Canada who doesn't have that weird Canada / US hardware translation unit built into their brain, it's painful. It's the dates. The US, alone, uses mm/dd/yy. The rest of the world except for Belize uses something vaguely sensible. Even Canada. Except Canada has a ton of systems imported directly from the US (or shares systems with their US parent companies) so lots of dates on things like receipts are in the form mm/dd/yy. Or they are dd/mm/yy. You can't tell. 06/07/17. Guess the date. Canadians can tell, just by looking at the date whether it's June or July. To me that's impossible yet they seem to do it. Somewhere a programmer decided to output the date this way. Either they just used the default date formatter or they deliberately choose a dd/mm/yy or mm/dd/yy format. 5 seconds of work would enable them to output in dd-MMM-yyyy or dd-MMM-yy or even yyyy-mm-dd or yy-mm-dd format. Either of which would allow a high level of accuracy in guessing the date. I'm sure they also thought, at the time, that their decision was a valid one. It wasn't, and it made me wonder whether we as developers have a responsibility to ensure that the information we present to the world is always presented unambiguously. Is this something you do? Is it something your lead actually stops you doing? Or is it something you've not really though of?
cheers Chris Maunder
Wow, I was surprised that this is even a question but pleased so many believe they are responsible for a user-friendly UI. Absolutely, even if the programmer is given specific specifications, they need to validate what the user experience will be. We do not program stuff just to move data around. Ultimately a user must interface with the information and when they do, it should be as intuitive as possible. Nothing is more crazy making for the user than a UI that is confusing or ambiguous when the designer and programmer (and the whole team) have the power to make clean sensible user experiences.
-
In my own writings I always use big endian dates, always with a 4-digit year, and may change e.g. the naming of files receceived to suit my preferences. I also move the date ahead of any descriptive term, so that it starts the file name / table entry / whatever. Main reason: It allows sorting on the date (which is my most common sorting criterion) as text. But I have a slight feeling of being somewhat nerdy when I do so. Humans can sort the dates as they were originally written; my rewriting is for the machine, not for humans. And, I must admit, I frequently do not do it that way for other kinds of data. My address book is not sorted big-endian but little endian. If someone asks me for my birthdate, I state it in little-endian form - and that is a date. Time of day is usually little endian ("ten to nine" - "eight fifty" sounds like something from an army guy). Friends are named by their first name preceeding their family name. Little endianness is, in a way, user friendly in that it focuses first on the nearness, and then gradually puts things into a bigger scope. Big-endianness either requires you to start with the universe and narrow down from there, step by step - otherwise, it might be ambiguous. If you make a new friend, telling him where you live may be limited to giving the street name and number; the town, county, state, nation, continent, planet and galaxy are implicit. So, little endian may be more user friendly. Actually, you have a similar issue in programming! In most programming languages, the opening of a statement may identify it as an assignment ("X = ..."). But after the assgnment operator, which gives you the Grand Overview of the statement, you dive deep into the details of the expression, with priority rules en masse, some of which are so obscure that you have to ignore/override them by use of parentheses. The APL language is 100% consistent: No priorities, main things first, and if you want details, continue reading. "X = 3 * ": X is being changed, that is the essential thing. It is being set to 3 times some calculated value, no matter how it is calculated; in most cases, the 3 has high semantic importance (e.g. number of units bough). If you want the details, read on to break the up. If you only need an overview, you can read only the first parts of the statements. And I have worked with languages going the other way (but with operator priorities): "(A+4) * B =: C" - first assemble the pieces, then tell what to do with it (i.e. storing in C). Th
Member 7989122 wrote:
So how do you correctly sort a table of names containing both Norwegian and Swedish names?
Got similar issues in my home tongue Afrikaans, lots of áâäèéêëïôöûü going on, not to mention other characters from French and German which made their way into it as well. Usually for sorting purposes I tend to first convert them to an invariant culture, you do get some decent libraries which are pretty fast with this.
Member 7989122 wrote:
Our endianness is inconsistent in hundreds of areas; dates is only one.
Definitely correct. Even just addresses is a problem over here (well not so much a problem as an inconsistency). E.g. in English you state number then street, in Afrikaans it's the other way round, but in both they're then followed by suburb/area, etc.
Member 7989122 wrote:
Big-endianness either requires you to start with the universe and narrow down from there, step by step - otherwise, it might be ambiguous.
Not completely in agreement here. If I follow the same principle for little-endianess, the same idea then means you never stop until you reach the universe. And the same idea about stopping once it becomes obvious can be applied to big-endian too: Only start where you think it's no longer obvious (e.g. don't state the country if you're already there). To show an example of big-endian we very commonly use: Telephone numbers. We seldom state the area code if they're in the same city, we even more seldom state the country code when they're in the same country. Just because they're big-endian doesn't mean people HAVE to start with the universe.
-
I manipulate and persist dates/times in an unambiguous fashion. I present them according to the user's preferences as indicated by the Windows locale or other mechanism.
Software Zen:
delete this;Like a good developer should, thank you very much. But in the current "developer" world (i.e. Silicon Valley style), minding that "not all of your millions of users are from the US" is a mind boggling concept. You think dates are bad? How about keyboard short-cuts that absolutely cannot work (looking at you Android Studio)? Everytime a see a "Ctr+/" or something like that, it's apparent that nobody tried the software with a non-US/UK keyboard. (hint, most naturalized keyboars use key combinations for (), [],\, etc.. So shortcuts that require those keys will not work.
-
Actually I'm not sure why we don't stick to more fundamental units like that. 2π rad = a full circle - what could be easier? And frankly I'd be happy to switch to Kelvin if it meant never having to look at another negative temperature.
cheers Chris Maunder
Tau master race. 𝜏 = 1 full circle. Fuck π!
-
Yeah, I liked that Oracle defaulted to dd-MMM-yy and we used that a lot. Over the years, I ultimately prefer some variation of YYYYMMDD and use that as time stamps for files, etc. I find it sorts nicely, is total unambiguous, and when combined with YYYYMMDD_HHNNSS it still sorts, and moves the ball forward. But don't get me started on AM/PM... Who thought of that? And what were they thinking? And timezones, and Daylight savings time. Obviously not a lot of computer planning went into any of this when the first PC could not represent a date before 1/1/1900 lol. Finally. Where is the metric system when you need it. There should be 10 seconds per minute. 10 minutes per hour, 10 hrs per day, and 10 days per month, etc... How much easier would life be then?
> 10 seconds per minute. That would be a very short minute. In fact, it would shorter than what we call a "moment" (around 20 seconds, since the middle ages)
-
Your time example actually proves my point more than yours. The format you like: dd/mm/yyyy is in decreasing significance order, meaning most specific to least specific. So if you were to extend that with time then it would be ss:mm:hh dd/mm/yyyy. But I am sure that seems ridiculous to you. We all use cultural rules when choosing how to display data. Do you also insist that in languages that are read from right-to-left that they should switch to left-to-right because you feel it suits more people? If you were designing a UI with a status indicator and you chose a fairly standard red/yellow/green scheme would you refuse to change it after finding out your users were colorblind because the scheme suits more people? The point is that it is how your users feel about the way data is presented that matters. That is a higher responsibility than adherence to rules you feel are "universal".
How many man-decades of work have been wasted debugging and fixing shit that developers like you make? Data must be unambiguous, and the user experience must adapt to the user (locale, formatting, etc).
-
Like a good developer should, thank you very much. But in the current "developer" world (i.e. Silicon Valley style), minding that "not all of your millions of users are from the US" is a mind boggling concept. You think dates are bad? How about keyboard short-cuts that absolutely cannot work (looking at you Android Studio)? Everytime a see a "Ctr+/" or something like that, it's apparent that nobody tried the software with a non-US/UK keyboard. (hint, most naturalized keyboars use key combinations for (), [],\, etc.. So shortcuts that require those keys will not work.
André Pereira wrote:
How about keyboard short-cuts that absolutely cannot work
I have been through that scenario. I create user interfaces for our line of commercial ink-jet printing systems. Our UI is largely touch-screen driven. For one product line I implemented several locale-specific on-screen keyboard layouts for entry of file names and such. Most of them were fairly easy, except for the Japanese, Korean, and Simplified Chinese. For those I sent photos of the physical keyboard to colleagues in-country, and had them send me text files with the keytop characters encoded in UTF-16.
Software Zen:
delete this; -
André Pereira wrote:
How about keyboard short-cuts that absolutely cannot work
I have been through that scenario. I create user interfaces for our line of commercial ink-jet printing systems. Our UI is largely touch-screen driven. For one product line I implemented several locale-specific on-screen keyboard layouts for entry of file names and such. Most of them were fairly easy, except for the Japanese, Korean, and Simplified Chinese. For those I sent photos of the physical keyboard to colleagues in-country, and had them send me text files with the keytop characters encoded in UTF-16.
Software Zen:
delete this;Quote:
photos of the physical keyboard
Quote:
had them send me text files with the keytop characters encoded in UTF-16
That's a very hands on solution I like it. It's something a script kiddie could do, instead of researching the whole thing. But no, they just look at their Mac and that's it.
-
You prove yourself the way you like, but nothing meaningful to me. If some doc needs timestamp, it's quite easy: "17 Feb 2017 15:27" - format understandable by all humans in the world. Everything else you wrote - TL;DR
Using an abbreviation of a localised String is what you call "understandable by all humans in the world"? I hope no-one ever lets you near a UI.
-
Using an abbreviation of a localised String is what you call "understandable by all humans in the world"? I hope no-one ever lets you near a UI.
-
I'm going through expenses, and for anyone living in Canada who doesn't have that weird Canada / US hardware translation unit built into their brain, it's painful. It's the dates. The US, alone, uses mm/dd/yy. The rest of the world except for Belize uses something vaguely sensible. Even Canada. Except Canada has a ton of systems imported directly from the US (or shares systems with their US parent companies) so lots of dates on things like receipts are in the form mm/dd/yy. Or they are dd/mm/yy. You can't tell. 06/07/17. Guess the date. Canadians can tell, just by looking at the date whether it's June or July. To me that's impossible yet they seem to do it. Somewhere a programmer decided to output the date this way. Either they just used the default date formatter or they deliberately choose a dd/mm/yy or mm/dd/yy format. 5 seconds of work would enable them to output in dd-MMM-yyyy or dd-MMM-yy or even yyyy-mm-dd or yy-mm-dd format. Either of which would allow a high level of accuracy in guessing the date. I'm sure they also thought, at the time, that their decision was a valid one. It wasn't, and it made me wonder whether we as developers have a responsibility to ensure that the information we present to the world is always presented unambiguously. Is this something you do? Is it something your lead actually stops you doing? Or is it something you've not really though of?
cheers Chris Maunder
Some fresh anecdotal feedback: I just saw my app's reviews for last month - LiveStickies, a simple app I published for Windows Store. All of the reviews refer 2 things: "thank for the UI" (my pleasure), and "thank you for supporting language/characters/shortcuts". This just by supporting more languages than just English, even with only 2 or 3 translations. Hell, I even took 5 minutes to make sure support right-to-left systems is working. You think the hipster silicon valley designer is going to even consider that 1/4 of the word population, when that population doesn't use a left-to-right writing? It's our job.