|
My HP Elitebook has a variation on the eraser that does not move. It seems like it is pressure sensing.
My only gripe:
I have a small notebook, so the necessary small screen is killer on my 50+ eyes. I am glad all apps have zoom features!
|
|
|
|
|
As the subject line says - not something I came up with, but I like it. I stole it from this discussion when researching the topic.
In any case. Not a programming question.
I like to label my fields, listboxes, etc so if the user is only allowed to make a single selection, the label is singular. If the user is allowed multiple selections (including just one), I like to indicate it as such by using a label such as "Widget(s)" (as opposed to "Widgets"). Maybe I'm thinking like a developer (or so I'm told), but to me the parens make it clear making multiple choices is possible, but still just an option.
One of my coworkers hates this. Or to use the example from the discussion at the link above, something like "Party(ies)".
What's your preference? Or has your company adopted something formal?
I'm thinking this might be a good survey question.
|
|
|
|
|
If 1 - Singular
if 1 or more - Plural
|
|
|
|
|
But do you use the plural version using the parenthesis, is really my question. That's what my co-worker hates, to the point of having searched our entire codebase and checking in "corrections"...
I'm okay with that...just wondering what the world at large thinks...
|
|
|
|
|
I wouldn't put Parenthetical Pluralization in a UI. Even a Tooltip should be along the lines of "Select one or more Widgets", "Select up to ten Parties".
In documentation sure, but only when it's a simple (s) , (ies) is an abomination. Better to reword the statement to avoid the issue and possibly the meaning will be clearer as a result.
|
|
|
|
|
PIEBALDconsult wrote: In documentation sure, but only when it's a simple (s), (ies) is an abomination You should see what they are doing here in Germany with the genders in texts...
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Nelek wrote: You should see what they are doing here in Germany with the genders in texts...
That has crossed my mind. I'm French, and it's not uncommon to see those sorts of things in ordinary documents written in French, so maybe that's where I adopted the idea. My co-worker only speaks English; not being used to associate genders to nouns, I think, is the reason he sees this as being out of place.
|
|
|
|
|
Are you trying to acomodate ALL gender forms in the same word?
Example:
Worker (m): Arbeiter
Worker (f): Arbeiterin
Workers (m): Arbeitern
Workers (f): Arbeiterinnen
Now you have to write: Arbeiter_innen, Arbeiter*innen, Arbeiter-innen... to be political correct.
And you can not imagine how tiring it is to read a text full of that crap.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
No, ultimately my UI is only targeting English, so gender is not an issue.
In French, you Worker example would become:
Travailleur(euse)(s)
...and I have seen such a thing in documentation.
But still, I agree, if it went beyond just singular vs plural, I'd standardize on one thing only.
|
|
|
|
|
|
What a waste of effort, 2 keys to insert a parenthwhatever and adds very little to the readability of the code, actually I think it detracts from the readability. Besides the information should be in the comments!
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
I think he's using it in the UI, not the code...
|
|
|
|
|
Yes, I'm talking about labels visible in the UI.
|
|
|
|
|
Works for me. I use for clarity at little expense.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
|
kmoorevs wrote: '1 record(s) returned'. or worse '1 records returned'. C'mon, it only takes a few seconds to handle it correctly!
I do that, rather obsessively. 1 is singular. Everything else gets an 's', including 0.
|
|
|
|
|
kmoorevs wrote: C'mon, it only takes a few seconds to handle it correctly!
At least one time I was told that for grammatically correct Chinese that numbers change based on something. Not necessarily gender but perhaps even/odd.
So not so easy if one wants to internationalize it.
And if one wanted to use the written form of the number, so 'one' rather than '1' then gender would definitely play a role in multiple languages.
|
|
|
|
|
In Stock, On order, Invoice Items ... are more instructive. "Widget" is a "type of" field and maybe shouldn't even be a "label". Depends on the context.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
dandy72 wrote: I like to label my fields, listboxes...One of my coworkers hates this...What's your preference? Or has your company adopted something formal?
My preference is that people would recognize that a UI should be written with the user of the UI in mind and not the developer.
That said of course for any UI that is actually going to get used substantially the user is not going to care about small oddities in how the boxes are labeled. After just a short while they will intuitively know what each box is without reading anything at all.
What they do care about is that the UI and the rest of the application actually works. So might be better to focus on that.
|
|
|
|
|
Maybe use regular expression suffixes?
Widget must select 1
Widget+ must select 1 or more
Widget* may select 0 or more
Widget? may select 0 or 1
Every coder will agree. Suffix should be added automatically based on setter methods argument.
0 maps to nullable type or List.
Widget -> setWidget(Widget w)
Widget+ -> setWidget(List<widget> list)
Widget* -> setWidget(List<widget>? list)
Widget? -> setWidget(Widget? w)
I would probably still pass an empty list to the * method over a null.
Widget spelling is start to look really weird after typing it so many times!
Good luck!
|
|
|
|
|
englebart wrote: Maybe use regular expression suffixes?
I'm already being told I'm "thinking too much like a programmer" and that normal people get confused by that. I don't think regular expression suffixes would go over very well. 
|
|
|
|
|
But the team member that took the time to remove the “(s)” from every label might LOVE the idea and do all of the work! 😁
|
|
|
|
|
How do you feel about online data storage? Is it really secure?
Paranoid.
|
|
|
|
|
The data can be technically secure, but then there's always this...
xkcd: Security
With this out of the way...
If I absolutely, positively, had to upload data I don't want shared, I'd only be uploading TrueCrypt (or similar) file containers. That'd be missing the point of convenience, but that's hardly ever part of the question when it comes up.
|
|
|
|
|
I use OneDrive as it's the easiest way to share stuff between my desktop, Surface, and phone - but if it's anything I don't want public, it gets encrypted first. (Even if it's just "normal" photos with identifiable humans in).
Is it secure? I assume it's at the "Chocolate Teapot" security level.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|