It's not an extraordinary claim, it's a mundane and plausible one. This is exactly what you get when you ask an LLM to write in a "engaging conversational" style, and skip any editing after the fact. You could never prove it but there are a LOT of tells.
"The key insight" - llms love key insights!
"self-contained corruption-free" - they also love over-hypenating, as much as they love em-dashing. Both abundant here.
"X like it's 2005" and also "Y like it's 2009" - what a cool casual turn of phrase, so natural!
The architecture diagram is definitely unedited AI, Claude always messes up the border alignment on ascii boxes
I wouldn't mind except the end result is imprecise and sloppy, as pointed out by the GP comment. And the tone is so predictable/boring at this point, I'd MUCH rather read poorly written human output with some actual personality.
Do you have a different example other than 20 Days in Mariupol? Because the filmmakers definitely didn't watch that and think it could "make them buck". Principal photography for Civil War took place the year before 20 Days in Mariupol premiered.
Ah ok, stupidity on my part in both cases! It actually does work, but after skimming the description I assumed it was for styling 'View Source' tabs. Which would be a great feature btw.
The other image, the logo, is probably generic enough that it's used elsewhere and a user is likely to have it cached. The other looks bespoke for this page, so wouldn't.
I don't understand how it validates - I'd always understood that html, head, [title] and body were required for a complete document. Certainly the draft spec at http://www.w3.org/TR/html5/semantics.html#the-html-element-0 appears to confirm this ...
Fairplay to them though, they got a semantically and structurally deficient document to validate - it's like the IE6 of webpages ;0)
That's a strange version of "required". Basically the elements are not required in a document until parse time at which point they are inserted following an extremely arduously defined algorithm.
It seems bizarre to me that you wouldn't simply define the location of meta elements strictly as being in the head but instead define that should the parser find them they should be wrapped in to a head element.
On a brief view it looks like one can just drop a meta tag, say, in anywhere in the document and the parser has to move this to the head element?
I didn't realise that they were encouraging tag soup; this isn't part of the spec I've seen before. This sort of complex parsing algo wasn't in XHTML1.X or HTML4.X was it?
The complex parsing algorithm wasn't spelled out in excruciating detail, as it is in HTML5; much of it was implied, and left for the parser developers to figure out.
Strictly, the HTML, HEAD, and (BODY|FRAMESET) elements are required, in a valid document, but the tags delimiting them are optional. That way, code which manipulates the DOM can always count on a HEAD element being present, and CSS specifiers can use 'body' as a root, even if the tags themselves are missing from the source HTML file.
The first actual required tag in an HTML 4 document is <title>, as far as I know. Every HTML document has to have one, and it needs to be opened and closed explicitly. If it's the first thing in the document, it implies an <html><head> before it, and if body content comes after it, that will imply </head><body> as well.
You could put a <meta> tag anywhere before the first body content, and it would still be part of the implied HEAD element. As long as it doesn't come after the (explicit or implicit) </head> tag, it shouldn't cause the document to fail validation.
And no, none of this is valid XHTML. XHTML is always strict, and all opening and closing (or self-closing) tags must be present in the source file.
I don't think the older ones do; however, I'm sure Google gives them a different 404 page (change your User-Agent to IE6 and see how different the search results HTML is).
Which could be another indication why the Google logo itself is linked (besides it being in cache as well). The page degrades well imho in IE6 - the lack of the cutsey robot isn't essential to the page - the logo however is.
Base64 isn't exactly efficient. (Though it might be more efficient than an additional HTTP request. But if so, why aren't they using it for the homepage logo, say?) I wonder if they're using it as non-useless padding for stopping the IE-overrides-too-short-404s behavior.
* How can you not have a robot-eating-pizza logo! :)
* WAY too many different fonts and text styles. I count 12.
* Get some better/more appetising food photos
* The text boxes change size when selected, causing the layout to jump.
* Edit and cancel button icons jump 1px on hover.
* The cancel button has a text-selection cursor instead of a pointer
* The flat grey header doesn't really go with the wood panel effect.
* Wood panel bg repeats too soon with a visible join.
Results page:
* Overall very good, nice and clear
* The login pop-up needs proper styling
* I'd consider making the phone numbers always visible, rather than with the address expander. The first action if you're in a rush it to call a bunch of places to check reservations.
* The dollar signs to indicate price are a kinda ambiguous. How must is a $$$ meal compared to a $$$$ meal?
Thanks for the great feedback. Some thoughts/responses:
* Robot eating pizza logo - Great suggestion! Definitely need a good logo, and will consider this when reaching out to a graphic designer / 99 designs.
* WAY too many different fonts and text styles - Guilty as charged. Will fix this in future updates.
* Get some better/more appetising food photos - Believe it or not, these are actually improvements over past iterations. But I will keep my eyes open for something even more delicious (although if you have food images suggestions, I'm all ears..er...eyes..er, stomach?)
* The text boxes change size when selected, causing the layout to jump. - Noted. Will add to list of things to address.
* Edit and cancel button icons jump 1px on hover. - Should be fixed now
* The cancel button has a text-selection cursor instead of a pointer - Should be fixed now
* The flat grey header doesn't really go with the wood panel effect. - Noted
* Wood panel bg repeats too soon with a visible join. - Fixed the visible join
* I'd consider making the phone numbers always visible, rather than with the address expander. - Interesting point. I've also had requests to make the entire address visible too. I go back and forth between making more info visible immediately versus keeping the results cleans and simple and providing more info on a need-to-know basis. Sounds like you think phone # is more vital to expose earlier.
* The dollar signs to indicate price are a kinda ambiguous. How must is a $$$ meal compared to a $$$$ meal? - Yes I can make this clearer. The system is the same as Yelp's for restaurants, but I should add a legend calling this out more or somehow make this more obvious.
Thanks again for all the great feedback. Super helpful.
Very impressive and ambitious UI, lots of great attention to detail. Click-and-drag selection highlighting in particular. Here's some observations about the interface whilst I was exploring. This is Chrome/Ubuntu.
On the document search page:
* Double-click to open isn't intuitive for me on a website. Had a few puzzled seconds wondering how to open a document.
* Middle-click to open is broken.
* If I try to do a drag selection starting over a thumbnail, it doesn't work.
* The browser right-click context menu isn't always suppressed, and completely obscures your custom menu. Maybe float it to the left of the cursor so both are visible?
* Seems like the thumbnail/list view switcher buttons are the wrong way round.
* If I select multiple documents then click download, nothing happens. Either grey out the option, or add zip downloading.
* Selecting 'view pages' when in thumbnail view breaks the layout.
* The 'Page x of x' navigation at the bottom is non standard without being any more useful. Found it annoying having to actually type in the page I wanted to go to. Duplicating the pagination nav at the top of the page would be nice.
* Left-hand document list is well thought out, like that the scrollwheel works, but it still feels a bit awkward. Not sure why.
* 'Entities' seems too specific to describe what are essentially tags. Caused a bit of confusion. Phone numbers and 'terms' are not entities.
* The 'Log In' button is a bit out of context next to the other buttons. Maybe move it to the top right next to your logo?
* As the document links are taking me off-site, I'd like the statusbar url to still appear on hover.
* Found myself focusing the search box just so the text was dark enough to read.
Document viewer:
* The document sidebar might be better on the left. Having it on the right breaks Fitt's law for the scrollbar.
* Arrow key and spacebar scrolling doesn't work on document load. You have to click to focus the document first.
* The document page navigation might be better in the top bar, rather than the sidebar. Having it in the sidebar gave me the false expectation of sidebar content that changed related to the page I was on.
* The 'Pages' thumbnail view only seems to show up for some documents.
* The zoom level I set for the 'Pages' view also changes the zoom level for the 'Document' view. So I can't easily browse with tiny thumbnails but fullsize documents.
* Annotation UI is great, very intuitive. The restrained use of colour on the rest of the site really pays off, that yellow is hard to miss.
* With two notes parallel to each other cause their markers to overlap, example:
Thanks for all the notes -- this is incredibly helpful. I clearly won't be able to address all of these today ... but I'm definitely printing this list out and taping it on the wall.
No problem, I've got plenty more- modal dialogs have green close buttons! 'Sort by' button doesn't show current sort type without clicking, etc etc. DocumentCloud looks like a fantastic project, I'd love to help out if you need it.
I think the Pandora handheld is much more exciting.
http://www.open-pandora.org/
Specifically this- "But the most interesting part is probably that it isn't designed by a large company, it was designed by the suggestions and requests of hundreds of people on the gp32x forums."
The form factor is very impressive considering the sheer volume of physical buttons and i/o options. Even more so considering it was design-by-committee. Could have been hideous.
The tour pages are really well put together content wise; When trying to decide if a program is worth a downloading, I usually scan the screenshots page and make a quick decision based on first impressions. Comes across as easy to use but with some nice power features.
The landing page screenshot has been poorly resized however. I'd make that a bit bigger and prettier, and you could even go so far as adding slick little javascript tooltips to explain different tools. Could help your conversion rates maybe? Also perhaps consider using the same shiny green 'Try It Now' button on the bottom of the tour pages, instead of switching to a text link. Small grammar nitpick, 'How it works' is not a question.
Yeah gimp does ugly resizing. Python image lib would probably be better, or if you have access to photoshop that works very well of course (bicubic sharpen setting). Or email me the file if you like. :)
Other ideas- I'd make the top blue gradient extend the whole width of the page. If you're going to make your signup buttons with fancy css shadows etc, might as well do the same for your logo text rather than having it in an image. Any reason for the lack of spaces in 'Wireframing&Prototyping'? You've got 'learn more' text in two different formatting styles on the landing page. No need for external links to open in new tabs, your users will be savvy enough to use their back button. I'd consider burying the 'get it free' in the footer rather than by the buying info - perceived value and all that.
I've emailed you the original image. Thanks for looking into it.
I've just started improving the website design and striped headers and footers are next on my list. I need to figure out how to do it with Blueprint CSS. CSS buttons is something that I've added only a week ago. I've used the fancy-buttons plugin for compass to do it.
I've fixed that '&' everywhere. It didn't occur to me that there should be spaces. I've also fixed the links.
I actually thought about placing the "get it free" section somewhere else or removing it altogether. I thought it was a good strategy to acquire as many users as I can.
"The key insight" - llms love key insights! "self-contained corruption-free" - they also love over-hypenating, as much as they love em-dashing. Both abundant here. "X like it's 2005" and also "Y like it's 2009" - what a cool casual turn of phrase, so natural! The architecture diagram is definitely unedited AI, Claude always messes up the border alignment on ascii boxes
I wouldn't mind except the end result is imprecise and sloppy, as pointed out by the GP comment. And the tone is so predictable/boring at this point, I'd MUCH rather read poorly written human output with some actual personality.