41–50 of 50 posts
One thing that confused me a little at first, UI wise, is the scroll bars on the page Web Results and Image Results panels. I was just scanning pages and thought the page was hanging for some reason while using my mouse wheel.
This is so cool, it shows you're a real developer's developer, if you get what I mean! One thing that confused me a little at first, UI wise, is the scroll bars on the page Web Results and Image Results panels. I was just scanning pages and thought the page was hanging for some reason while using my mouse wheel.
I don't have a comment on the work itself, but like most sites, it has no awareness of line length, and it's therefore painful to parse the information without resizing the window. Both HN, and the linked website, could benefit greatly in readability by simply limiting line-length to ~32em for textual information. It's strange that a browser, designed for human use, has no notion of humans in that regard.
Hey, xjay. If you do a hard reload in your browser, you should see that the encyclopedic data is now bound to a 32em width (with a smaller font size). Does that look a bit better to you?
Thanks for considering the feedback.
PS: The typographical rule I based 32em on comes from the general rule that, there should at least be room for two alphabets (a-z) on one line. I found 32em to be a sweet spot. The em unit scales in proportion to whatever pixel size you choose for the font, or whatever font size I tell my browser to enforce, so it's highly consistent.
PPS: Another bonus for having a sensible maximum line length, is something I'd never thought about unless it happened to me. It's the nuisance called eye floaters. It's basically an obstruction that floats around in your vision. So whenever the eye moves, the obstruction will dash across your field of view to follow, before coming to rest again. The less the eye has to move in general, the better.
PPPS: For HN (and wikipedia) I eventually ended up making a CSS rule that would override the width of various sections, to comply with the human inside. It's just that there is no line-length attribute, so it must be hacked together specifically for each trouble site.
I don't have a comment on the work itself, but like most sites, it has no awareness of line length, and it's therefore painful to parse the information without resizing the window. Both HN, and the linked website, could benefit greatly in readability by simply limiting line-length to ~32em for textual information. It's strange that a browser, designed for human use, has no notion of humans in that regard.
I'd say that resizing windows to make text readable should be normal and using maximized windows on todays large displays makes little sense, but... I was looking at that site myself on a maximized window :-) Why? Because I had other tabs open with developer tools and I needed all the space. So yes, sites should set line length and line spacing appropriately. When we see lot of white space around a column of text we…
Imagine if we could divide a tab into regions of sites instead?
Having a maximum line length is the humane thing to do, unless the person has phobias of empty spaces, of course. :>
The links you provided are not for the user, but for the designer. Text, however, is a global means of communication, so it should get better treatment, and care in general. Especially by browsers.
Earlier quoted context omitted.
Hey, xjay. If you do a hard reload in your browser, you should see that the encyclopedic data is now bound to a 32em width (with a smaller font size). Does that look a bit better to you?
The idea is to have a maximum line length that makes sense to human beings, and that's what the site does now. It is very pleasant to read the text. Thanks for considering the feedback. PS: The typographical rule I based 32em on comes from the general rule that, there should at least be room for two alphabets (a-z) on one line. I found 32em to be a sweet spot. The em unit scales in proportion to whatever pixel size y…
Earlier quoted context omitted.
What would be really awesome (and probably insanely difficult to make) is an API which does something similar to what Google does when you define: stuff. It usually comes from a dictionary, but sometimes it has more interesting sources. I'd love to put something like that in an IRC bot.
This is even more experimental than the main service, itself, but does something like this meet your needs (genuinely curious)? https://tuvalie.com/fae/?q=Albert%20Einstein&api
So when specifying "Albert Einstein" Google gives:
> Albert Einstein. BrE. (1879-1955) a physicist, born in Germany, who was possibly the greatest scientist of the 20th century. In 1905 he published his theory of relativity. This led to the equation giving the relationship between mass and energy, E=mc2, which is the basis of atomic energy.
But when specifying "hubbub" Google gives:
> a chaotic din caused by a crowd of people. "a hubbub of laughter and shouting"
Stuff like that, where it (somehow) automatically determines which piece of information is most relevant. Again, I don't think this is really doable without having as much search data as Google does.
Earlier quoted context omitted.
215 million facts, that's impressive! Anyway, congratulations on shipping. If you ever want to collaborate on search, please let me know.
I'd love to find ways to collaborate with anyone who's interested :) I also forgot to mention that you can download an export of (most) of the timeline events from http://endlessorigins.com/ -- I update it from time to time with new events, too. To my knowledge, it's the largest freely available structured data set of historic human events. Could that be useful to you?
Also, I think it's a bad idea to offer common financial codes as recovery codes for your site (SSN, mother's maiden name, etc.)
Registration rejects email addresses with certain characters ("+" at least) Also, I think it's a bad idea to offer common financial codes as recovery codes for your site (SSN, mother's maiden name, etc.)
This is so cool, it shows you're a real developer's developer, if you get what I mean! One thing that confused me a little at first, UI wise, is the scroll bars on the page Web Results and Image Results panels. I was just scanning pages and thought the page was hanging for some reason while using my mouse wheel.
Thank you! I can honestly say that comment put a smile on my face. As far as the scroll bars go, I just didn't want to take up too much screen real estate for those individual sections. (So that people who want to spend time with them can, but those who don't can skip over them a bit quicker.) Do you think there's a better way to handle that? I'm very open to suggestions for just about anything!
My feeling is to either make liberal use of "Click to expand" or to just let users scroll the whole page vertically. I think we've become used to long, vertical content elements.