havoc wrote:
so theres reason going on after all. anyways, i have few comments:
Pirat wrote:
I had zero problems with it
you shouldnt EVER assess the situation by yourself - whatever you do will be used mostly by other people, and (sadly) they are not Pirat.
I never claimed that this page won't cause problems on someone's PC.
Because nearly
every software processing some data can lead to problems
somewhere. There is always a set of thresholds that someone creating public
content (programs, web pages, ...) decides for.
I tested the very Google Images result page with even more pages (IIRC
over 60 pages) on my old Thinkpad with sucky single-core CPU and very sucky
graphics card, and -- surprise -- I still had no problems with it, just what I
expected (save the problem that your example page needs JavaScript, which
I don't use in my default browser).
Now let's look at the technical facts:
- That Wiki page had about 300 kB pure text. As the server gzips the page, it
gets shrunk to a whopping 6 kB! - Each entry would have had a thumbnail JPEG smaller than 10 kB.
So first, the browser loads 6 kB of text (that takes less than a second even with
GPRS). Then, while the browser loads the thumbnail images in the background,
you can immediately start browsing or searching. And with an average 1 MBit
connection, the images are loaded after 18 seconds. If you are on a very slow
connection (GPRS etc.) and don't want to wait for a specific image to be loaded,
you can just right-click on it and choose "View Image" (and then go back and let
the image loading process continue).
havoc wrote:
like, if i do webpages as i like them, they will look like gopher. to other people this will be text on white background, and guess what - most 'normals' go into panic attack when they see text. like they have fear of reading or something, but are ok to press shiney buttons, just like monkeys.
Although you might not believe it, we think the same. I
am concerned about
accessibility. My former homepage had a relatively simple design -- and for those
guys using Lynx or other textbrowsers that didn't support HTML tables at that time,
I additionally manually transferred my HTML tables to preformatted ASCII tables!
If
that isn't devotion to accessibility, I don't know. For the same reason, I never
used JavaScript, Flash or the various proprietary extensions to HTML.
But of course, tempora mutantur, and you cannot make
everyone happy.
Because making the remaining 20 per cent happy needs 80 per cent of your
resources (man "pareto principle").
havoc wrote:
Pirat wrote:
search the whole page with the normal browser search
2 things here - "search the whole page" - that means you are already lost m8, if you have to search thru it. i know it doesnt feel like you are, but you are.
Maybe my elevator doesn't go all the way to the top, but could you try to
explain to me what you mean with "you are already lost" in this context?
It is the
data itself that might "make you get lost". It doesn't matter
if you search a single HTML page or if you enter search strings into
some frontend: In both cases, "you are already lost".
havoc wrote:
"normal browser search" - no theres nothing normal in it. it may be normal to you, but not for the 'normals'. i can assure you 9 out of 10 dont know the browser has a search. yes, thats a power-user option, and you my friend are a godly hacker compared to the normals.
Oo ... errr ... okay, for the sake of argument, let's just assume that 90 per cent
of our gamers (i. e. the target group for the map list) don't know about the browser's
search function. How in the world should I have implemented that DokuWiki map list
otherwise?
Your suggestion was to divide the list into sections of 10-20 map entries.
But how would have that helped the browser-search-agnostic people? The only
difference is that on the big page, they scroll, and on the sectioned page, they click
on prev/next. And above that, as resectioning the complete list is extremely tedious,
your suggestion of just adding new entries to the last page would make matters
worse -- for both browser-search-agnostic and browser-search-aware people.
Not wanting to bash your suggestions, I'm glad if people help me, but IMHO, with
the DokuWiki as technical platform, I still see no alternative to a large HTML page
-- and even that didn't work for server-side resource problems (which Wursti offered
me to fix, but I prefer to do without that terribly inefficient DokuWiki and instead
implement something more suitable).
havoc wrote:
Pirat wrote:
I'm sorry, but I really love simple and efficient interfaces.
[Apple's 1-button control]
over-simplification does not necessarily lead to good results.
ACK. Nor does over-complication. :-)
havoc wrote:
Pirat wrote:
It's 2012, bro! :-)
exactly my point!
Finally, we have something in common! %-)
havoc wrote:
========================
tl;dr - keep an open mind. listen to havoc.
:-)
havoc wrote:
anyways, not trying to argue or something, just giving you some pointers out of my experience to think over, hope you find them useful.
I appreciate any input (provided that fucked up Pirate haz the nerves to process it %-).
havoc wrote:
if you need help, squeal on irc.
Thanks!
Peace cannot be achieved through violence, it can only be attained through
understanding. ~Ralph Waldo EmersonSo you better understand me !!111one ;-)
(and make me understand you, of course!)
<3
Pirat
.