At various points I've wanted to upvote an entire pool or artist, not just a post (or, more recently, a comment). How about it?
Posted under General
evazion said:
Here are some recent statistics on resolutions. 1024x768 is still the most common resolution.
Including 1024 (0r 1024 - 440 or whatever) isn't a bad idea, I was only saying that a lot of people have larger monitors, and it would be good to facilitate them as well. 1024 looks sort of small to me since it only uses 60% of my screen's width.
Steam also has another source for checking out prevailing hardware trends. According to their data 1280x1024 is the most prevalent (19.90%), but is less than a percentage point more common than 1680x1050 (19.19%). It also shows both formats are losing ground to HD (both 720 and 1080) though each of those is still only about 1% of the population.
Updated
DschingisKhan said: At various points I've wanted to upvote an entire pool or artist, not just a post (or, more recently, a comment). How about it?
By that, did you mean mass up-voting each individual post in a pool, or did you mean being able to up/down-vote the pools themselves?
If you suggested the former, that probably wouldn't be a good idea; all posts should be up/down-voted on an individual basis. And if you meant the latter, I don't think voting for pools or artists would really be something we need.
evazion said:
Here are some recent statistics on resolutions. 1024x768 is still the most common resolution.
Going by width, that says 20% of users are using 1024 px wide screens, while 37% have 1280px.
w3counter's stats have 1024px at almost 30%, but I'd guess w3schools' are more indicative for this site.
Samples are currently 850px wide. It wouldn't be a bad idea to have an option closer to highres.
Chainsaw_Guitar said: would it be possible to move the ratings into the tags? that way we could blacklist any tag beyond a "safe" rating and remove any need for Safebooru
Can't you just use rating:s (safe), rating:q (questionable), and rating:e (explicit) for that? You can already add all three of those to your blacklist.
Adding both 'rating:q' and 'rating:e', or just '-rating:s' (it's a negated search, so it'll blacklist anything that's not rated safe) to separate lines in your blacklist could very well accomplish what you've asked.
EDIT: Or you could even do a search like this, for example: animal_ears -rating:s. I'd also suggest reading the Danbooru cheat sheat.
Updated
I've decided to switch to git. It's available here: http://github.com/r888888888/danbooru
I will work on core tag/post/user functionality first, updating the tests along the way.
I would also like to suggest the option to hide comments, without impacting that comment's score. I sometimes find comments that are quite useful or informative (such as extensive artist's commentary, related info, or translations that wouldn't fit due to the file being a flash animation) that I want to skip past, without having to scroll up and down excessively.
On that subject, I'd also like to make all comments' scores visible, and possibly also with a tally of how many votes have been cast on the comment.
Sort of a relatively minor thing, but I was just thinking that perhaps provide the ability to directly embed images inline to wiki pages. In many cases we need to link to an image as a prototypical example anyway, it would make as much sense if that image was simply displayed alongside the text and not require the user to click off to another page to see it.
evazion said:
I highly doubt that there is a significant difference between Danbooru users and typical web users. It would be easy enough for albert to collect statistics on this to check.
The only way to determine client resolution is using Javascript as far as I know. 1024x768 probably would be less common here since I'd wager a significant number of those screens are in offices and hence less likely to be visiting this particular site. THe proliferation of netbooks will be bringing the average size down somewhat however.
Experimenting with pics of those resolutions (480px: post #611979; 1280px: post #611198) and the Web Developer extension, I'd say these are fair compromises, though medium is slightly small.
1280 shows up nicely on a 1680x1050, 1600x1200, or 1080p monitor without being knocked off screen by the sidebar. It's slightly too big to avoid horizontal scrolling on anything smaller.
480 gives you about the same margins on an 800x600 monitor, which is probably the lowest common denominator for anyone on the web in the last decade. It also looks decent on 1024x768, though it's a bit small for anything higher resolution than that.
I imagine most people with a ≥1600px wide monitor will default to large, people with ≤1024px wide monitors will be happy with small, and many people in between the two will end up with a fair bit of white space.
I would consider additionally having a size between he two, but if defaulting to 480 saves significant bandwidth, or if having three resizes eats up too much storage, it's probably not a bad idea to leave it as you plan.
Updated
albert said: I will generate resizes at 480 (medium) and 1280 (large) width. This more or less replaces the former sample implementation. Whether you want to see the medium, large, or original image will be an account setting, but by default medium will be shown.
Probably a dumb question, but the browser width-based Resize option will still exist, right? I don't use samples, but I do use that quite a lot and find it useful/.
jxh2154 said:
Probably a dumb question, but the browser width-based Resize option will still exist, right? I don't use samples, but I do use that quite a lot and find it useful/.
Yes.
I mainly choose 480 because that's the base resolution for most smart phones. And at 1280/1024 (which represents about 50% of the visitors here) it's not too small. Flickr defaults to 500, and I think defaulting to a small resolution would help with bandwidth.
Speaking of resizing, you could look into doing content aware image resizing. Here's a demo of it implemented in javascript.