Posted by theandrewbailey 3 days ago
Also poor form is to have your download button on github.io pulling an executable from malware sites like sourceforge. I'm looking at you wxMaxima.
A website is a website. To download is to download. The mechanics won't be 'abstracted away' just because you don't call them with the proper terms.
To see our latest news, click here, or click here if you want to request a catalog. The latest board minutes can be found by clicking here. Click here for product documentation. If you have any comments about our web site, click here to email us, or click here to call. If you were confused by this click here, or click here to let us know it met your expectations. Click here to see how many people have visited our internet web site.
On the plus side, there was actual useful content on the web, rather than the content-free designs that popped up in the Web 2.0 era.
> See our latest news, request a catalog. The latest board minutes. Product documentation. If you have any comments about our web site, email us, or call. If you were confused by this, let us know it met your expectations. See how many people have visited our internet web site.
Which imho is not any better, and arguably worse.
See our latest news
request a catalog
Read the latest board minutes
Product documentation
email us with questions about our website
Call us
So a little indicator that these are links without "click here" and now the link text is very informative. But this would look like a menu.
These days I don't think you'd find many people following this style guide, but I think I understand what they're going for. They seem to be making the prose neutral to the technical details; after all, if you're keyboard navigating, maybe you're not "clicking" per-se. Maybe the pages are printed onto paper, etc.
Now I really wish the page elaborated a bit more. I do wonder if there's any logic to avoiding "website" or if it's just the different choices they made in the examples.
I would suggest that "click here" is more concise, meaningful, and well understood than "follow this link" or alternatives.
In cases where you want to do something involving a call to action, like "Click here to download", I think "Download" or "Download now!" are better. And hell, often times CTAs are better as buttons (at least visually) than links anyways.
That said, it's not like I follow this religiously. But anyway, I think it's highly likely people are taking away the wrong message here.
I guess to put it another way, it's not that the terminology we use is dated or wrong per-se; I mean sure, people tap on hyperlinks more than they click on them these days probably, but the point isn't that the terminology is dated or isn't understood. It's that well-structured hypertext can avoid it altogether.
Firstly because of the acceptance of "click is to web as dial is to phone", that the term "click" as a verb meaning to follow a navigation link or interact with a button, or generally interact at all with something on a website or app. I think this is useful and should be encouraged [0].
Secondly because it was used in the first place because it was very clear instruction. "Download" by itself assumes that the user knows how to download, and if the UI element isn't clear that it's a link or a button (or interactive) then that's not obvious how that should happen. "Click here to download" is much more clear, obvious, and helpful. I think it was old-school SourceForge that had "Download" buttons that didn't look like buttons, and ran adverts that had very prominent "Click here to download" buttons, and that ended up being very confusing and getting a lot of people to click on shitty ads.
Thirdly, and purely as a matter of personal taste, I don't subscribe to the design philosophy that less is better. I prefer clear instructions to ambiguous ones, even if that means more words. The impulse to surround everything in whitespace, remove scroll bars, and make it look pretty at the cost of usability should be discouraged imho. A button should look like a button. It should be clearly labelled with what it does, or what you need to do to make it do the thing. I realise I'm in a minority here, but that's not unusual.
[0] though maybe the new verbal usage of "I'm double-clicking on this concept" to mean supporting it is probably a bit much.
If you need to disambiguate or further clarify links, well, you should also set the title attributes too. That ought to help.
I'm pretty sure the W3C is not recommending you do that. If you link to the Amaya website, link on the text "Amaya". If you're linking to something else Amaya-related, modify the link text appropriately.
Remember, in ~2010, it was a trend to add toolbars to Internet Explorer (it was called BHO I think?)
These toolbars were changing the search engine for Bing, Yahoo, etc. This is why they were called "Yahoo toolbar".
But then, came Chrome, which was bundled among other in:
- Adobe Flash Player updates
- Java Runtime Environment (via Oracle)
- CCleaner
- Avast and AVG installers
- Many download portals (e.g., Softonic, CNET Download.com, SourceForge)
So, the objective of Chrome, instead of replacing the search engine with a toolbar, it was to do it by installing a new app, but this is exactly the same goal. At the end, the goal of Google was not the save the web, it was to replace the search engine and display ads on these pages (+ make sure that the targeting + rendering is under their control).
- Toggle/hide aria-hidden items from the page so you can ensure only the important components are there
- Show the ordered list of links, headings, landmarks you'd see in screen readers like when you use the VO+U rotor in macOS VoiceOver
- Toggle on a mode where a little "?" appears next to anything with an aria-description that can be hovered as a tooltip
Prob would be a decent start.
Though I recommend the more curious HNer to fire up macOS VoiceOver, do its tutorial (Settings -> Accessibility -> VoiceOver -> "Open VoiceOver Tutorial..."), and then navigate your own website. Use Safari for this since it has the best VoiceOver behavior.
It's very eye opening (heh) and helps you understand what things like aria-hidden actually are for.
If that's not enough, it also prepares you for bad luck in the future, and it's also just cool being able to use your computer with your eyes closed.
I had some classes in uni where we weren't allowed to use our laptop screens, and I bet I could have gotten away with having my hands inside a half closed laptop with an airpod in my ear scrolling HN/Reddit while the professor droned on for an hour.
https://www.w3.org/WAI/WCAG22/Techniques/html/H33
https://www.w3.org/WAI/WCAG22/Techniques/css/C7
However, I don’t know how well the first one is supported by screen readers.
(Edit: Updated the links from WCAG 2.0 to 2.2.)
https://www.w3.org/WAI/WCAG22/Understanding/link-purpose-in-...
I did sweat localization with this approach. We use a workflow to ensure some peer review but it's an added challenge. Seemingly all good.
I would still include more of the action, i.e., ”Get Amaya“ instead of ”Amaya“ as in the article.
Crucially: screen reader navigation is NOT the same as keyboard navigation.
Anyway, "click here" is more accessible for anyone else, since links should look like links, and random half-bold words in a wall of text are not cutting it.
Click here for screen reader accessible version
It’s like… ‘click here. No, here. Left a bit. Almost. Come on, you can get it. What are you, blind or something?’
You can use something like macOS VoiceOver right now to see how it behaves.
Yes, exactly, if ARIA tags haven't been provided. It's not exactly rocket science to have some heuristics that check if a link is solely "click", "click here", etc., and it reads the entire sentence if that's the case. Seems like it would work 99+% of the time with exceedingly little effort.
There's no expectation, and should be no expectation, that the function of a link should be derivable directly from the text it encloses.
Besides, AMP is the almighty master of this practice, and they’re not trying to help disabled people, they’re trying to control the internet.
1. https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
2. https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
3. https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
4. https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
The larger issue is that developing software for multiple platforms and multiple browsers and multiple different types of human interface devices (from eye tracking to sip-and-puff joysticks) from dozens of vendors is an extremely complex affair.
Users may even employ multiple different screen readers in different contexts to work around incompatibilities.
Sure, sure, we need to accommodate people with disabilities. First step to get there is to make sure the accessibility software isn't trash.
The Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act. The ADA, specifically Title III, applies to public accommodations (including websites), requiring them to be accessible. Section 508 mandates that federal agencies ensure their electronic and information technology, including websites, is accessible to people with disabilities.
The EU Web Accessibility Directive and the European Accessibility Act (EAA) are key pieces of legislation aimed at improving digital accessibility for people with disabilities within the European Union. The Directive focuses on public sector websites and mobile applications, while the EAA expands accessibility requirements to a wider range of products and services, including those in e-commerce, banking, and travel.
And, I benefit greatly from accommodations around accessibility. Both in the physical world and online.
Is this how you want these discussions to go?
I guess at some point this button gets a bit worn out and I start wondering what pushing the "do something about it" button will do.
Yes.
If I had "Amaya!" as the link text to download something, I'd be not much better off and would reach for context too.
What's the problem with reading the surrounding text or the URL?
Yes, or it can summarize the text and explain what the link is to.
They don't try to be helpful, they only do exactly what they are told.
Frankly I think there's rear space for interruption here, particularly with AI.
[1] https://www.powermapper.com/tests/screen-readers/aria/
[2] https://www.powermapper.com/tests/screen-readers/labelling/i...
Why is it embarrassing to need to code against standardised accessibility interfaces so that other tools using those interfaces can function? Is it embarrassing to have to code against a database or filesystem interface to persist data, or a graphics interface to show pictures?
This is how software should work. Attempting to be "helpful" usually makes things worse. Doing exactly what it's told makes it predictable and usable.
Just look at how much of the HTML 5 spec is a nightmare of parsing rules for handling malformed SGML. Look at how it got there - all the invocations of Postel's law justifying attempting to handle malformed input in "helpful" ways, until things were eventually such a compatibility nightmare that a new spec was created to give precise rules for parsing every single input the same way. "Helpful" was specified away, because it was so broken.
Now if only screen readers provided consistency in following rules, too. They're not in a great state, but your attempted solution is worse.
I'd reckon 90% of 'accessiblity' software was written by a sighted or hearing dev that thought they had an idea that would be 'helpful'.
Simply either read the surrounding text (possibly by additional instruction) or the URL. I can't fathom how that's a difficult task.
> To download W3C's editor/browser Amaya, _click here_.
Is extraordinarily clear. I'll click the link and it will either download directly, or it will be a download page.
In contrast:
> Get _Amaya_!
That suggests a link to the Amaya website, not a download page. That's not effective for a download.
Similarly:
> Tell me more about _Amaya_: W3C's free editor/browser that lets you create _HTML_, _SVG_, and _MathML_ documents.
This is terrible. It's not about downloading, and "tell me more" is the command, but not linked! For all I know, the "Amaya" link goes to a corporate landing page, not the "tell me more" information I actually need.
The conventional uses on the web are totally fine:
> To download W3C's editor/browser Amaya, _click here_.
> _Download Amaya_, the W3C's editor/browser.
The idea that links shouldn't be verbs seems very silly to me. Links should absolutely be verbs, when they involve an action like downloading or finding out more. Obviously that's different from "reference" links like in Wikipedia, where you're finding more about a topic.
And "click here" makes it exceptionally clear that a link isn't merely a reference link, but an action link. When I see:
> Get _Amaya_!
That... doesn't tell me how to get Amaya. That tells me "Amaya" is a reference link, not a download link.
Build a search engine. What information does "click here" offer your index?
I agree with you that verbs don't seem all that problematic. Except when the verb is click and the object is here. I can stomach a link whose text is "Click Here to download Amaya," but if the link is literally just the two words, "click here," it is indistinguishable from others in many different contexts.
The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.
https://www.w3.org/WAI/WCAG21/Understanding/link-purpose-in-...
Having a single word announced by the screen reader to me would fail this criteria.
The problem here is that the screen reader will just read the link text and not the contract around it.
I would encourage you to read OP's comment first?
A list where: “Click here” to download “V 16.23.4” has two links one of which gives info on the download and their other starts a download is fine, especially if the info page also has a download link.
If the download link is on the information page, a simple solution is just to send people to the information page where they can download. I tend to prefer that anyway. I find premature direct download links to be jarring where I’m not expecting it.
When using a mouse pointer, you also want that information as a tooltip.
It is an interesting point, because in 2001, what is a link was usually clear and standardized: blue, underlined, often both, like on the article page. Now, just look at Hacker News, only the links in comments are underlined, and they have no special color, you have to mouse over if you want to know. And Hacker News is not in any way special in that regard.
So I would argue that "click here" is more relevant now than it once was. Same idea for buttons by the way. They used to look like, well, buttons, often with a 3D look. Now, there is often no real difference between a button and regular framed text. It means we need more context to guess which is which.
Click this hypertext link: <a href="more-info.html">More Info</a>
Put the device specific call to action outside of the link, and make the link say what it links to, not what physical action to take to follow the link.
Anyway, mobile phone touch screens don't click. Saying "click here" is like using a floppy disk as a save icon.
Obviously for the same reason you also should not say "touch here" either. Touching your desktop computer's screen doesn't work unless you have a touch screen, which is rare.
That's the point, why saying "click here" or "touch here" is always wrong.
...have you ever used a mobile phone? Clicking is the only action you can take on one.
> Anyway, mobile phone touch screens don't click.
Let's check the dictionary!
https://en.wiktionary.org/wiki/click
- (verb) 2. [intransitive] To emit a click.
Phones don't do that, but that can't be relevant to the text "click here" because that text is directed at the user, not at the phone.
- (verb) 5. [transitive, graphical user interface] To select a software item using usually, but not always, the pressing of a mouse button.
Hmm....
Or is your entire point that you think it's actually a good idea to put the words "click here" in links? Then explain why?
Please consider reading the rest of this thread before you keep fighting developers to do it your way.
After that if you still want "click here" that's your call but at least be open to better alternatives rather this dismissing this discussion.
With enough experience you learn that what is obvious is less obvious than it appears.
Are you saying that you need links to say "click here" in order to understand what to do?
Then how did you manage to navigate to this discussion and press the reply link, which did not say "click here"?
Do you not think this looks like superfluous noise at all?
click here for mat_b click here for 1 hour ago | click here for undown | click here for root | click here for parent | click here for prev | click here for next click here to collapse [–]
bla bla bla
click here for reply
accessibility is usability. build products that are usable by people. that's all.
So of course usability can decrease usability, readability can decrease readability, accessibility can decrease accessibility, beauty can decrease beauty, and all those desirable traits can decrease each other, because there is no one single "technique" you just apply mindlessly to achieve any of those goals.
There are many many ways of achieving (and ruining) each of those goals, and you constantly have to balance and trade them all off against each other.
If somebody is so lazy and careless and poorly educated that they always use links saying "click here" as a solution to their problem of not being creative enough to come up with a better more descriptive link, I can guarantee you 100% of the time they are not going to give a flying fuck about aria or even have a clue what it is.
Most of us never wrote an aria attribute in our life.
But I haven't used "click here" as anchor text in 20 years because it sucks for these reasons.
We are used to small areas, but the problem is that you end up with 'click here', like in the example. But if you linked the whole text, it's basically the same thing as adding aria.
IMO, most cases that I see using aria seem like a fix after the fact vs doing it the right way.
There are use cases for it, but in the case of the example, making the whole sentence a link would be good.
Regarding screen readers, you can have it read all links, which is why the 'click here' is an issue. So you want a balance. Change "for x, <a href=...>click here</a>" "<a href=...>for x, click here</a>"... ta-da?
You need to optimize for people using accessibility tools, but also for the people looking at the site...
No, you want the verb to be whatever "x" does or is for, not the action taken to get there. The action taken to get there is the same for all links regardless of what they're for. So this is a bad example simply because we don't know what "x" is so we don't know what a better verb would be.
I think that signals to visitor using screen readers and without, what that is and how to interact with it.
If someone with a screen reader is jumping through links, they'll get context for the link. A visitor not using it will see get the context since it's all highlighted together. Someone using a keyboard, the outline will highlight all of it.
I am just a keyboard user. I have no idea if this is the best way. But I think it gives the same info to everyone.
It would be an extraordinarily easy for screen readers to have a heuristic that whenever a link is just "click here" or common variations like "tap here", "click", etc., to read the entire sentence containing the link. It's not exactly rocket science. Yes, you need an internationalized list of strings to detect. Also, if aria-label is present, just use that.
Likewise, search engines are great at inferring meaning from the page as a whole. I'm not going to change my link text for the benefit of search engines.
There may not be a surrounding sentence (e.g. in a "PDF"/"Download" link). The surrounding sentence may not add any/enough additional context, e.g. "You can click here for help." or "To view the article [one of many] you can click here.".
You then run into issues where 1) the screen reader/AT is overriding the ARIA/a11y markup on the page against WAI-ARIA and WCAG standards; and 2) you can end up with different behaviour on each screen reader, in addition to the places they already differ.
It's bad enough when web browsers introduced heuristics on form labels such that "name" + "label" fields were detected as a login form and other situations where bad heuristics were used and the web browsers overrode what websites were specifying.
> Yes, you need an internationalized list of strings to detect.
Who would maintain this list and be the authority for every language on Earth?
We've managed to get this far without needing such a central dependency.
It's not a "central dependency" that needs an "authority". It's just part of building internationalized software.
Shouldn't screen readers have intelligent heuristics to most appropriately convey context when required? Seeing as most of the web doesn't have accessibility annotations?
While the long-running trend of SEO stuffing from low-value content farms has polluted search results for years now, Google didn't really care about fixing that problem because there's a perverse incentive to generate more ad revenue by making the first page results usesless. Who cares about doing the right thing? Daddy's got to get his quarterly numbers up. I should also note that those content farms were also early adopters of genAI as we know it today.
Infinite growth isn't a thing. Every cancer eventually kills its host.
This is such an echo chamber. Most people love AI. It's one of the fastest growing types of content across all social media.
The news media is telling us we hate it (eg. John Oliver, 404 Media), but this is not the mainstream consensus. Views and likes don't lie.
"Normies" think this technology is magical. Some organs of the traditional news media are trying to skew their opinions.
If you're saying you have relevant stats, then please, share the stats.
it's become a trope to the point i know i can ctrl-f "screen reader" if literally anything ui related is being discussed
On the whole I'd say it's a good thing because it means that the various awareness campaigns are working. Better that this kind of stuff is "overdiscussed" than not discussing it at all.
And besides, this focus has some useful side effects. For example, pages designed with screen readers in mind are also that much easier to interact with from scripts and other automation.
That's similar to replacing all major doors in a building with automatic ones that can't be operated manually and take forever to open, despite the typical occupancy by wheelchair users being 0. Accessibility is great, but accessibility for few should not come at the cost of accessibility for most.
Using accessible link text doesn't cost the same as adding an automatic opener to every door in a building.
Therefore, the ``click here'' works best for me.
PS
- "_Get Amaya_" should start a file transfer.
- "Get _amaya_ over there!"
sounds like "okay next site will be info dump before actual download", which is acceptable to gather trust like brand or imprint recognition over there instead of googling now.The Newpipe app on Android has such a mode for Youtube descriptions.
They do - Firefox has the option "Search for text when you start typing". I have it enabled for decades.
> That suggests a link to the Amaya website, not a download page. That's not effective for a download.
In all their examples, the link is to the homepage of the Amaya website, not some download page (never mind the actual download).
It seems their message is watered down quite a bit by conflating the issue around "click here", which as other comments have said is an accessibility issue, with whether the text accurately reflects the target.
- To cancel this purchase [click here].
- To complete this purchase [click here].
I do agree with you about verbs.
In your example, I would expect the download page of Amaya to be titled "Download Amaya", so my link can simply be "If you are interested, [Download Amaya]!"
You think of them as action, they're not.
Actions are for applications. You are reading a document.
They are metadata.
Think of them like "footnootes" of a paragraph, or references.
Remember, you're reading a document, not using an application.
I'd suggest:
_Download Amaya here_, W3C's editor/browser
or
W3C's editor/browser: _Download Amaya here_
> Links should absolutely be verbs
No, links imply a verb: ‘get.’ Buttons imply another verb: ‘post.’ It’d be awesome if there were ways in HTML to indicate other verbs, such as put and delete.
> > Get _Amaya_!
> That... doesn't tell me how to get Amaya.
No, it doesn’t: it is a document calling its reader to action. That’s something a document does: it tells a reader how to do something, or calls the reader to do something. Clicking is just an artifact of a particular technology at a particular point in time (heck, I imagine most people nowadays don’t click, because they are using smartphones — they tap instead).
The principle is something I agree with and try to abide by, though.
As an analogy, consider how you would feel if the instruction manual of your microwave oven (or other physical appliance) would instruct you to "click" its buttons. It's not that you wouldn't understand what to do or that you'd be looking for a mouse port, it's that the word wouldn't be the right one for the circumstance.
Incidentally, as a keyboard user I sometimes feel that way when there are instructions to "click" some UI button, but I will press the appropriate keyboard shortcut instead.
“The best tires” becomes “the best vehicular solutions”
I find it funny but I will say that passion often produces amazing results.
Good design is accessible by nature. Otherwise it’s just sparkling wank.
But yes, in general you're absolutely right, that a good designer will take into account all factors, including accessibility. But the way that "design" has evolved in practice in means that the thing we all think of as "web design[er]" is not optimizing for it.
Not everything done in the name of accesility makes it accessible to all, nor does accessibility have a necessary correlation with 'good design'.
That's not to say we should't strive for both and require accesible solutions, but let's not pretend putting lightswitches 40" from the floor or those bumpy concrete pads in grocery store parking lots are better for everyone.
W3c says:
Get *Amaya*
Read more about *Amaya*
*Get Amaya*
*Read more about Amaya*
Personally, I think both are confounding two different use cases. Links are often used inline in text. The use case that W3c and the Home Office are addressing are use cases that would be better address by out-of-line buttons:
[Download]
[Documentation]
To use a concrete example, how should one rewrite the following?
PiPedal is a guitar effects pedal that runs
on Raspberry Pi. To download PiPedal, *click here*.
To read the documentation, *click here*.
PiPedal is a guitar effects pedal that runs
on Raspberry Pi. Get Pipedal. Read the documentation.
Pipedal is a guitar effects pedal that runs on
Raspberry Pi. To download PiPedal, visit the *Download
Page*. To learn more about Pipedal, view the
*Documentation*.
Ubuntu Server installs don't suffer from this problem;
but before choosing an Ubuntu Server install, you
should read the *Ubuntu Server* section of the
"Installing on Ubuntu" page.
And in the very first example given, the text is from a lede in a web page where concision matters.
To download PiPedal, click *here*.
[ Download ] [ Documentation ]
To download PiPedal, visit the *Download Page*. PiPedal is a guitar effects pedal that runs
on Raspberry Pi.
You can *download PiPedal*, and learn more
in the *PiPedal documentation*. PiPedal is a guitar effects pedal that runs on
Raspberry Pi.
*Download PiPedal* now (MIT license)
or read all about it in the *PiPedal documentation*.
Yes, those buttons may not be "in context" when the page is not being viewed in a visual medium.
> To download PiPedal, click here.
Another appropriate link in this case could be simply:
*Download PiPedal* now!
To *download PiPedal*, visit the Download Page. PiPedal is a guitar effects pedal that runs on Raspberry Pi. *To download PiPedal, click here*.
*To read the documentation, click here*.A link that just says "Amaya" could be an internal or external link, and even if it's clear from context that the purpose of following the link is to download Amaya (rather than, for example, read more about it), it's not clear whether it's a direct link to the file or a link to the download page.
Note that aria-label does not work properly in all cases, e.g. when the browser chrome uses a different language than the site itself.
I think of "click here" as stage direction mistakenly left in. When most authors write, they often don't write in a hypertext context. Instead of using a Markdown-like notation for links, they default to stage direction.
So links to my website are fine, while links to my website are inherently not. I also have a strong pet peeve around imperative tone, so I'd never write something like go to my website or follow this link.
> Ignoring the garbage on Web pages is a skill that some people don't have, and I don't know how to teach it. I'm reminded of this each time I try to help someone who doesn't have my background, use the Web; there are users who look at the literally first thing on the page and think about it carefully, even if it's "Please enable notifications," before they see the second item on the page at all.
> With Google searches now offering multiple screenfulls of garbage before the actual results, well.
> A related issue is failing to understand the epistemic status of different kinds of text on a page. E.g. the user who sees a clickable link with the text "I forgot my password" and believes that that means it's telling him he did forget his password (and it somehow knows this?), rather than just being the place to click if he forgot his password.
> The death of UI standardization, of course, makes this issue much worse.
I remember when Microsoft removed many buttons from their UI and replaced them with vaguely colored text (links) and it became a lot harder to figure out what to click on.
Users intuitively adapt themselves to the machine and developers adapt themselves to the users forming a feedback loop.
To put it another way: the meaning of language has probably been changed by so many websites and apps having an "I forgot my password" link. At least in that context most humans will adapt to understand the intent. Newer generations that have known nothing else won't even consider it to be worth their notice. In that sense there is also value in sticking to convention even if the convention makes no sense when considered in isolation.
Preferably with a download icon to indicate that it's going to be the actual file and not just a link to another page with the real download button hidden among 4 ads that are just download buttons.
Get *Amaya*.
Tell me more about *Amaya*.I guess technically, "To learn more about Amaya, view the datasheet." is also an imperative sentence. But to my mind, it scans better as inline text. Not quite sure how to nounify that one either. And interestingly, inability to find the "learn more about" link on landing pages for products I'm interested in is a source of constant frustration for me. There should be a word for "something halfway between the the breathless lede on a landing page, and "here's a thousand pages of documentation". For hardware products, the "datasheet" is exactly what I'm looking for; there doesn't seem to be an equivalent for software products.