Just wanted to comment on the clarity and effectiveness of the home page. Love it! So many user-friendly checkboxes are ticked off. Nice look, great description, plenty of examples, advanced usage section that's very easy to take in, credits at the bottom with some backend tech used, a welcoming contact link...
All of this accomplished (landing page and documentation) in just a few scrolls of the mouse. I went from novice to expert in a minute. There was a real effort to communicate with the end-user from an (empathic) end-user perspective.
Even the parsed json page listing a default 30 images (with credits) is easy to navigate with all the pertinent information available - including urls that open in a new tab (so a user doesn't lose their place on the origin page).
You mentioned in another comment that 400 million images are served per month. Yet... it has the feel (and performance and care) of a small static site.
Exactly. It took me under 30 seconds of scanning through the page to understand most of the API. No fancy badges, abstract graphics or buzzwords, just a direct demonstration of the value. This is how product pages should be.
One minor nitpick is the use of "random" where they mean "arbitrary". :)
Also, it's still a bit unclear how caching of images would work when you append an arbitrary parameter: text implies none of the images would be cached (presumably because of cache headers or browser behaviour), but I'd prefer it if they were indeed cached by browsers as distinct images instead (iow, soft-reloading X/Y?something=foo will give you the same image).
Basically, I'd like them to figure out all the caching semantics and behaviour, and just do the right thing ;)
I'm personally partial to PlaceKitten[1] though around halloween I will sometimes switch it up with PlaceZombie[2]
This one looks nice in that you wouldn't be embarrassed if it goes live since the images are generally nice looking but part of the appear of YAPHS (Yet Another Placeholder Service) is that it is really obviously a placeholder so you catch it before it goes live.
I wear corgi t-shirts, carry a little felt corgi keyring charm, have unicorgi stickers on laptop and tech bag both, my lunch bag is printed with corgis... there's a pattern here.
No. I live in a pet free building and also travel too much for the poor thing to be left alone.
I didn't mention five corgi plushies: one memory foam pillow and four Unicorgis. One pair of the Unicorgis are set to fly -- they had wings and the previous owner left hooks in the ceiling so it was pretty self evident what I needed to do...
says the person defending the personality of liking corgis as an abstract concept. you be nice and friendly and corgiless, i'll be grim and hateful while petting my corgi
I feel like this misses the entire purpose of lorem ipsum. Good layout designers don't just want letters and spaces. They want letters and spaces that approximate the whitespace ratio of writing. Your version has only very long words and very short words and nothing in between. This feels like the telephone game version where all of the original intent has been lost and all that's left is a weak simulacrum in vaguely the same symbol space.
When used for typesetting the Latin was intentionally scrambled, so even someone familiar with Classic Latin should find it more gibberish than not. For instance the `lorem` itself was most likely a chopped part of a longer word (dolorem).
An interesting comparison of the "Modern" typesetter's lorem ipsum and the likely source text is in the Wikipedia article:
I wasn't aware that Lorem Ipsum was conceived with uniform distribution of word lengths in mind. I couldn't find any information about it on Wikipedia: https://en.wikipedia.org/wiki/Lorem_ipsum
> The lorem ipsum text is typically a scrambled section of De finibus bonorum et malorum, a 1st-century BC Latin text by Cicero, with words altered, added, and removed to make it nonsensical, improper Latin.
Could you please provide source? I am curious now.
Alternate argument is that my version represents real actual text from real books :-), but to be honest, it is a tongue-in-cheek attempt.
"The point of using Lorem Ipsum is that it has a more-or-less normal distribution of letters, as opposed to using 'Content here, content here', making it look like readable English." via the 'Why do we use it?' section on https://www.lipsum.com/
I just posted the word length distribution graph on Github repo. In fact, contrary to the GP’s claim, Quantum Lorem Ipsum contains a larger % of shorter words than vanilla Lorem Ipsum. Also, the distribution isn’t perfectly normal. I used 16 paragraphs from both and wrote a small Julia script to analyze the word length.
I think the assertion that designers want to have a perfect normal distribution of word lengths is arguable. I’d be curious to analyze large datasets of books to see what the actual distribution of word lengths is. Heck, this may be an opportunity to actually fix vanilla Lorem Ipsum and write a script that can generate paragraphs that simulate real world distribution of word lengths! Looks like I have a project ahead of me this upcoming weekend :-).
On the flipside, maybe this version better emulates (a subset of) technical writing? So if you're tuning the design of e.g. a book or thesis, this is more representative than actual Lorem Ipsum?
I like it, but isn't one of the points of lorem ipsum that few people understand the meaning of any word and therefore get distracted? I just like to sneak-read yours a lot.
Ah, I was just about to say that this looks like unsplash.it (which we actually use in our SaaS to generate random images on our 404 and 500 error screens [0]). Glad to see that it is one and the same!
I recently launched http://joeschmoe.io, which is a similar API but for illustrated profile pictures. Did pretty well on product hunt and other places, so might be of interest here too :)
Are the photos scraped automatically from Unsplash or are they manually curated in some way?
I'm wondering because it looks like that website classifies photos by category (animals, architecture, fashion, food) but that information is not on your API.
I think it would be really useful to be able to get a picture of a random animal or a random landscape rather than just a random anything. But I'm not sure if that's outside of the scope of the project.
This site pre-dates the Unsplash license (and before Unsplash had their own API/website even, it started when they were still a tumblr blog), the images used on it is from back when Unsplash still licensed images under CC0.
We're on good terms with the Unsplash team, and think they're awesome.
I'm honestly surprised I haven't seen a placeholder service that serves up ads in the images. The service gets revenue, and the dev gets something that's obviously not a final product.
The service has actually been around since about 2014, currently, we serve about 400 million images a month, using some 6TB of bandwidth. It's pretty manageable since we use a CDN on top of the service, to cache already processed images.
Hoping to do a write-up of the architecture in the future, but the source and deployment setup is available at https://github.com/DMarby/picsum-photos if you're interested
I've checked out the source, thanks. I'll say that a write up on the architecture would be very interesting, if you ever make it then please post it on HN.
According to github looks like this came first. Seems like unsplash's attempt at making this? However this service doesn't seem to have rate limiting like theirs.
Wonderful, this may be.. IS the best product website I have ever seen!
If you have not thought about it: images does not really work for place holders for charts. Maybe placeholders for pie-, bar- and line-charts etc, can be a feature to come?
There's Google Analytics on the website.
For the API/service, there's no user/usage information being stored, other than aggregated bandwidth/total requests for the entire service, by our CDN provider, BelugaCDN.
You can find the source code, as well as the deployment setup here: https://github.com/DMarby/picsum-photos
It does indeed.
DigitalOcean is kind enough to sponsor the infrastructure, and BelugaCDN provides us with CDN services.
Any other costs I cover out of pocket / via carbon ads.
How did this sponsorship take place?I have a free server from a goverment program for University Students,but i am curious if you contacted them and talked about your project and they agreed.Same for Beluga
We switched over from our old NodeJS backend to a new Go backend recently, and gave the website an overhaul as well, things were a bit shaky during the transition.
I wrote the old codebase ~4 years ago when I was just learning NodeJS, and didn't touch it too much after that, so it was in dire need of being replaced, in particular since it wasn't really written to scale horizontally.
Didn't have any particular issues with NodeJS in terms of performance, just felt like using Go when I was rewriting it.
There are plenty of other good options indeed.
I created it in 2014 since I wanted a service that would give me nice looking pictures, rather than just coloured boxes or similar, for placeholders, there's not anything else to it.
I was noting it for the interest of the general reader, since the incredibly similar "Lorem Picsum" is garnering so much praise in this comments section.
Sometimes we are way too harsh and pedantic on each other. Instead of trying to help each other grow, we call our fellow engineers out for making decisions we disagree with.
This service is offered for free, and new routes can likely be added without trouble. It isn't like this is a choice that actually impacts anyone. It's merely a matter of style.
The only thing terrible here is the way the criticism is being offered. So I'm offering you feedback.
I guess it is not "terrible". I think the product can be improved in the manner suggested since it's heavily reliant on typing URLs manually, and I'm curious why the current format was selected. I am not discounting the entire product just because I am commenting on a very specific part of it.
It is a great site and idea, and I think many people have already suggested that.
Common pattern for such a service. There is no 'id' in the path, that isn't how it works, you just want the one path component for the size in order to return a square image and then if you give a second path component you get the y dimension. It is as simple as that.
I'm surprised it hasn't been written this way from the start, with the url rewriting on top. I don't know much about Go but in the "good old days" we would use apache to do the http stuff, including url rewriting, and {insert moudly language here} to just use the params it was given by the web server. It didn't matter if the url was rewritten for aesthetics or it used query string params. You could even run the same script from the command line. Magic!
Nowadays it seems like the front-end languages like to get their hands dirty in the url parsing for better or for worse. Often worse IMO. The application layer should be dealing with business logic, not http transport. Again, this just my (slightly dated) opinion.
Ugly yes, over engineering? no it's what you would have done in PHP in the 90's. Doing the URL thing would need more work (hello .htaccess). Anyway...
Good points: It is semantically correct and self documenting. There is no resource called 300 nested under a resource called 200 so lets not pretend there is. The query string seems perfect for the job of providing size parameters. You can then extend this interface to take other factors you want to affect the image, and keep it backwards compatible. Function over form.
It's using the URL as it was designed. in 21323/200/300, 200 is not a sub-resource of 21323, neither is 300 a sub-resource of 200. Specifying w and k parameters to the request is semantic and engineering accurate to the intent of the user
All of this accomplished (landing page and documentation) in just a few scrolls of the mouse. I went from novice to expert in a minute. There was a real effort to communicate with the end-user from an (empathic) end-user perspective.
Even the parsed json page listing a default 30 images (with credits) is easy to navigate with all the pertinent information available - including urls that open in a new tab (so a user doesn't lose their place on the origin page).
You mentioned in another comment that 400 million images are served per month. Yet... it has the feel (and performance and care) of a small static site.