Skeuomorphism didn't fail. It feel out of fashion with designers.
We should distinguish between skeuomorphic interaction design and skeuomorphic iconography. Attempts at skeuomorphic interaction design did fail badly, I'll give you that. Document readers that expect you to turn the page by pulling at the edge of the page, mimicking a page turn in a physical book, they're terrible.
But skeuomorphic iconography works: The more detail you add to an icon, the easier it is to form mental associations with what it does - and that goes even if you don't know the original object that it's based on. Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable.
> Sure, a lot of people have never seen the floppy disk that the traditional Save icon is based on, making the icon less intuitive now than when it was designed. But what would you replace it with? Any alternative you might suggest is just going to be less recognisable.
Obviously you replace it with the three stacked cylinders that symbolize a hard drive. ;D
It’s funny. The only people that regularly, seriously discuss skeuomorphism in software design are software developers. It was a big conversational topic among designers around the time Apple ditched the faux leather padding at the top of the calendar app. Developers started talking about it, I believe, because it’s an unusually concrete topic among typically abstract, nebulous, or artsy design conversations. Since then, there have been a zillion other big topics in the design world, and it’s largely considered a conceptual facet of design that’s just not very important. But developers, decades later, still discuss skeuomorphism in design like it’s one of the great important topics of the field. It’s not.
It would be like if smashing magazine put out an article in 2015 about everybody moving to a “microservices architecture” and then any time any kind of software development came up in a design forum, someone would awkwardly shoehorn the discussion into a framework of microservices vs monolithic applications. (Even better, when a developer would come along and try to give a more nuanced perspective, the designers would see themselves as the authority in the conversation because all the other designers around agreed with them.)
If you really want to dig into the nerdy conceptual side of icon design, triadic semiotics is the far more interesting rabbit hole to fall down.
This is exactly how our letters came about - 'A' originally was written sideways and represented an ox head, but now everybody just knows it as a letter.
I've seen an SD card icon used for a save icon before. I think conveniently the shape is similar enough to a floppy that you find it while scanning for it as well
If the text was returned using a staged process, whereby the server first returns an instruction (JavaScript), and the web browser then executes that instruction, which is what transfers the text, then that doesn't actually change anything. Those are just technical details of the transfer. You are viewing an HTML document on-screen; it makes no difference to this bet if it was returned to you by a different mechanism than originally conceived, since the bet doesn't specify any transfer mechanism, just that the URL was entered into a browser.
I understand that this isn't entirely clear-cut and that people will interpret it differently, but in my opinion, there is a significant difference between "a webpage that contains text X" and "an HTML document that contains text X." "Webpage" and "HTML document" are not synonyms - "HTML document" has a much narrower meaning.
Even if you interpreted the bet generously to allow for a browser to render the content using JavaScript, if I understand the bet correctly, the condition of working with a command-line tool like curl would fail.
I read the or's as giving alternatives, only one of which needs to work.
I can see how other interpretations are possible, but I don't see anything especially generous about mine. I'm not "allowing" anything: To make a judgement you have to pick a web browser to try it with, and you'd probably pick the most popular one, in the most popular configuration, that seems the most fair. If that web browser happens to execute Javascript when you navigate to an URL, then that's just how it is.
It says that the browser must download "an HTML document that still contains the following text". I can see how either interpretation could work, but I would interpret "contains" as "the text is in the HTML document", not "rendering the HTML document in a JavaScript-capable browser displays the text".
(Though, that said, some approaches to rendering sites via JavaScript would still have that text in the initially downloaded HTML file as JavaScript data.)
As for the "or", I read it as "doing either X or Y must", not "either X must or Y must (not necessarily both)", but yeah, I can see either interpretation being valid.
The big problem with the Turing test always was that it doesn't take into account adversarial designs. They had those chatbot contests about a decade ago, where the chatbots would regularly pass the turing test, not because the bots were intelligent, but because they were packed with rhetorical tricks designed to avoid saying anything of substance.
By any meaningful measure, today's LLM's pass the Turing test. Except we may need to lobotomize them for the deception to work.
Absolutely store the raw data. For the reasons you state.
But also store derived data. Titles, authors, dates, article texts. You need those for whatever your application does. You don't want your application logic to be working with the raw text.
> how will you handle updates to the feed?
When polling, consider using HTTP HEAD to check for changes before GET.
What you do when an article ID reappears with different content, that up to you. I think readers usually replace the old entry with the new content, silently. But it's not the only option.
- if you split the rss document into its "items" i am not sure if you can store each item separately inside postgres using that XML data type
- if you store the whole document, you end up with a problem when say the feed partially updates after a few minutes
- one suggestion i hear from r/PostgreSQL is that you store the XML blob somewhere else like hstore or something and somehow index it back to postgres. I wonder how that works conceptually / architecturally speaking
The data is probably small enough and infrequently updated such that almost anything will work. If you split the items then you would have a separate episodes table with one row per episode joined to the podcasts table. If you store the whole XML in a row then you can overwrite the row when the feed changes. Doing the parsing and splitting into episodes in DB sounds better to me because your clients will otherwise constantly be repeating that work.
I would say that's a very sugarcoated version of the Monster energy drink ingredients list[1]. The real list is ten time longer than the ingredients list of a cup of black filter coffee. And one of the items is "natural flavors", which could be hiding a long list of things all by itself.
For a piece of software designed by reading the specs and implementing accordingly, there acid3 would be a good way of demonstrating the quality of the result.
But is that what happened? If you pass tests that conflict with the specs, then that implies that the implementation is not based on specs, but on feedback from the test. Which means it may be designed to pass the test, and not much good once you go outside the test examples.
I'll extend the benefit of the doubt and say that it's possible that the implementation is based on an older version of specs, one that matches the tests. But it doesn't inspire confidence that all we're shown is a single screenshot and no source code.
Invisible until moused over, or scrolled by other means. Barely visible even then. In the wrong place. It may be "just styled", but it's certainly not fine.
If ease of repair is what you care about, then yes.
But in absolute terms, sockets do make things more likely to fail. A socketed design means you have an assembly step where something is put into that socket. Probably manually. Cables and sockets can be tugged at and twisted. Dirt and moisture can get in between. Suppliers can use the wrong metal in connectors. Some errors will be caught by QC, which means that you never see them, but they still affect the manufacturer's bottom line.
Like bot403 said: "Just depends on what your priorities are."
