What do you think of the way this menu works?

Hi.

I was faced with a non-functional menu component (that i wrote myself) when viewing pages with large menus on small screens.
I fixed the problem by making the menu work in an entirely new way, but would like some feedback on if you have an even better way for me to show these large menus on small screens, or what you think of how the menu works now..

It can be viewed (preferably in Chrome or Firefox or Safari) at http://seductiveapps.com and then go to the "Apps & Games" menu (top-left of browser window), then "Tarot v2 mobile". Wait for it to load, then go to the "Tarot Decks" menu and browse around that please..

 

The site is very slow.. also seems to be broken

This site will show soon.
9s, 679ms (2) - sa.uc.scan(): found and processed 0 cache items.
9s, 689ms (122) -
3s, 385ms (2) - sa.vividControls.init(): will now start to initialize 3 components (sitePopup_confirm, sitePopup_error, iframeContent, ), initID=0
3s, 396ms (2) - sa.vividDialog.init(): for initID=0; Initializing element with id="sitePopup_confirm" and class="vividDialog vividDialog__confirm vividDialog__keepHidden vividTheme__dialog_green_black_tiger_horizontal vividScrollpane__hidden".
3s, 402ms (2) - sa.vividDialog.initDialog(): using scrollpane theme "hidden" to initialize the dialog with id="sitePopup_confirm" and class="vividDialog vividDialog__confirm vividDialog__keepHidden vividTheme__dialog_green_black_tiger_horizontal vividScrollpane__hidden". Use class="[...] animatedScrollpane__auto [...]" to use the browser's default scrollbars for this dialog, or class="[...] animatedScrollpane__visible [...]" or class="[...] animatedScrollpane__hidden [...]" to not use any scrollbars at all.
3s, 408ms (3) - sa.vividControls.componentFullyInitialized(): initID=0; componentInstanceHTMLid=sitePopup_confirm, count=3, completedCount=1
3s, 411ms (2) - sa.vividDialog.init(): for initID=0; Initializing element with id="sitePopup_error" and class="vividDialog vividDialog__error vividTheme__dialog_black-gold_001_horizontal vividDialog__keepHidden vividScrollpane__hidden".
3s, 413ms (2) - sa.vividDialog.initDialog(): using scrollpane theme "hidden" to initialize the dialog with id="sitePopup_error" and class="vividDialog vividDialog__error vividTheme__dialog_black-gold_001_horizontal vividDialog__keepHidden vividScrollpane__hidden". Use class="[...] animatedScrollpane__auto [...]" to use the browser's default scrollbars for this dialog, or class="[...] animatedScrollpane__visible [...]" or class="[...] animatedScrollpane__hidden [...]" to not use any scrollbars at all.
3s, 416ms (3) - sa.vividControls.componentFullyInitialized(): initID=0; componentInstanceHTMLid=sitePopup_error, count=3, completedCount=2
3s, 420ms (2) - sa.vividScrollpane.init(): for initID=0; Initializing element with id="iframeContent" and class="content vividScrollpane vividTheme__scroll_black".
6s, 118ms (1) - imageLoaded() : loaded 1 of 8 images
6s, 125ms (1) - imageLoaded() : loaded 2 of 8 images
6s, 131ms (1) - imageLoaded() : loaded 3 of 8 images
6s, 133ms (1) - imageLoaded() : loaded 4 of 8 images
6s, 568ms (1) - imageLoaded() : loaded 5 of 8 images
6s, 571ms (1) - imageLoaded() : loaded 6 of 8 images
7s, 459ms (1) - imageLoaded() : loaded 7 of 8 images
7s, 461ms (1) - imageLoaded() : loaded 8 of 8 images
7s, 464ms (2) - sa.vividScrollpane.initScrollpane(): for initID=0; Constructing scrollpane HTML for id="iframeContent" and class="content vividScrollpane vividTheme__scroll_black".
7s, 474ms (3) - sa.vividControls.componentFullyInitialized(): initID=0; componentInstanceHTMLid=iframeContent, count=3, completedCount=3
7s, 478ms (2) - sa.vividControls.componentFullyInitialized(): all components for initID=0 are now ready, calling callback function
7s, 484ms (1) -

{
  "1": "appPage.source.js::startPage_do()"
}

Code (markup):

 

It can take up to 30 seconds for all the artwork to initialize.. There should be a progress bar as you load the page, do you see that?

 

hm the menu doesnt work perfectly yet, but you can at least figure out what i did to make many menu items manageable on smaller screens.

i'll be bugfixing the menu later today..

 

I think you should rethink how you are making your site as I have never really seen a site load like that, unless its an old flash site or something. Most users will think the site is broken, not working, or not trustworthy (virus/malware you scare the user).

You can do all of what your site currently does with CSS and some jquery, you might not even need any javascript actually. Here are some examples http://www.jqueryrain.com/demo/jquery-mega-menu/

Anyways, the site is very slow once it has loaded and the menu overlapped in FF 33, but it took like 3 sec to load each part of the menu which is way too long.

 

I know I've told you this earlier (not even sure I did it on this forum) - the page is HORRIBLE. It looks dated (like from the early 90s), it's slow as f*ck, and it has a color-scheme that breaks most good-design guides out there. Also, it breaks a lot of usability - I don't even wanna think how this looks on a screen-reader. Sorry - it's not gotten any better.

 

Just love the "Your browser is outdated" message in both REAL Opera (12.x) and the pathetic crippleware known as ChrOpera...

MASSIVE background image for nothing, page loads without actual CONTENT, zero graceful degradation due to endless pointless scripttardery, illegible colour contrasts, NO practical way to apply responsive layout to ANY of it, NASTY case of "semantics what's that?!?"...

SERIOUSLY... 2.7 MEGABYTES in 76 FILES JUST for the SCRIPTING?!? -- Do the world a favor, drag that mess of how not to build a website 'round back o' the woodshed, put a sawed-off to it's head, and put it down like old yeller. EVERY single garbage method of "How not to build a website" is present in it. Kill the stupid pointless javascript stupidity, use semantic markup (aka writing HTML properly), bend it to your will with CSS, and be done with it!

You are wasting EIGHT MEGABYTES on delivering one media embed and 5k of plaintext; If you don't know what's wrong with that you shouldn't be making websites.

 

For those that wrote constructive criticisms, like sarahk, thank you.
Sarah, I feel i have to show that bootlog until browsers become fast enough to initialize my site in under 5 seconds

For those that can't evolve with the times, where webgl will produce much larger files to download 'before anything's shown' than my website, well take your criticisms and spend some time in the retirement home
I'm convinced i'm on the right track to provide a much more pleasant user-interface than all those holy "standards-compliant" websites (my website is standards compliant as well)

And this website is not designed for screenreaders no. It's designed for fast computers and fast internet connections.

 

Well that's one heck of a delusion given that you can't even scroll anything in a reasonable amount of time on a i7 4770k... There's no interface focus, it's wasting hordes of code on Christmas only knows what... When it's an unusable bloated slow wreck at 25mbps on a i7 4770k with 24 gigs of RAM, you're doing something WRONG!

Did I mention I'm on a 25mbps connection / i7 4770k / 24 gigs RAM / 27" 2560x1440 display?

The rub of it is I'm not seeing a blasted thing that NEEDS anything like scripting much less webGL to even be done on the page; unless of course that webgl isn't functioning in Opera, FF or Chrome. (I didn't test M$ Exploder) -- and YES, I do have them enabled, your scripts are hemorrhaging errors that seems to stop it from even running! (which in two farking megs of scripting, good luck debugging that mess) -- seriously, have you even LOOKED at the error console in a browser with that disaster loaded?

You're not doing "the future" you're making the site completely unusable on EVERY platform. I can't find anyplace where the site does anything ... useful. I think what FF is doing is what you are aiming for, but I'm still curious about the big empty sidebar on the right, the bizzarre jerky scrolling of the main content area when I'm not trying to scroll it and painfully jerky and unreliable scrolling when trying to use it manually, etc, etc...

The real laugh being "evolve with the times" apparently meaning all the accessibility of something vomited up in frontpage a decade and a half ago... Ever heard of "emissive colourspace"? "luma calculation"? Dynamic and elastic fonts? ACTUAL modern techniques like semi-fluid, elastic and responsive layout? Graceful degradation? Progressive enhancement?

You seem to basically using "modern" tech to recreate this:
http://www.theworldsworstwebsiteever.com/

But, you want a bloated slow painful to use inaccessible train wreck, have fun with that. Apparantly you actually WANT a website nobody actually wants to use.

 

I don't think he is going to listen, especially if we are rude. I tried to be nice but I guess he skipped my comment as well.

I'm on a 100mbps connection with similar specs and do agree with everything you have said.

Anyways, he will see the issues when visitors stop coming and the ads don't earn revenue.

WebGL is pretty cool but it's not commonly used to make websites in the way you are. If you would like to explore WebGL there are many tutorials out there, here is a good link http://learningwebgl.com/blog/?page_id=1217

I am sure you could make some nice games or perhaps the first usable 3d website

 

BTW:

So sometime around 2060 I figure, since in handshakes ALONE regardless of connection speed or script execution time you have a best-case scenario of 16 seconds, and real world it's like a minute PLUS...

Also, if "this site is designed for fast computers" what the devil do you care about small screens? This wreck of scripttardery going to KILL any mobile device (say hello to five minutes battery life) You do know that a 1ghz ARM is roughly equal to a 450 MHZ PII, right? (since ARM is about performance per watt, not performance per clock)

I mean for laughs I tried it on my MSI G70 lappy with a i7 4700mq and 12 gigs of RAM, and with FF say hello to 100% on one CPU core, 30 degree temperature spike, and fan whirring up to full bore on AC. Don't even want to think what the battery behavior would be.

 

I tried this on my main computer, a quite powerful Dell XPS, full HD, i5 / 8GB RAM, SSD, on a 25/5 internet connection with no other stuff running. It loads the main site in 1 min 2 seconds, with over 400 files loaded, and over 8 MB, as @deathshadow mentioned.
While I'm usually all for using new tech ("new"), this looks too much like the olden days, when Flash was the epitome of useless design. I don't see the point. All the things you do with all this crap, you can do without webgl - replacing content? Check. Move things around? Check. Resize? Check. Change elements? Background? Foreground? Font? Check. I don't see ANY need for this "framework" for anything webrelated - it's already been solved by regular javascript (or javascript frameworks), and HTML5 / CSS3.
I don't see the point? Why would anyone use this bloated mess? And why do you insist on using colors and backgrounds etc. that noone uses? Colored (textured) menu-buttons? Why in the world? If you've spent ANY time looking at design, you'd know that less is actually more. Whitespace, color-coordination, a maximum of 5-7 colors (including b/w) for a design (with certain elements in one or two distinct contrasting colors for effect) and so on.

As for your statement about the future... I don't really understand where you think this future is? The current state of affairs is that most of the US, for instance, have crappy Internet-speed (for today's usage) - most US broadband sits between 2 and 10 Mb/s - and it's not gonna change anytime soon.
In Europe, the state of affaris is slightly better, but most users still have less than 10 Mb/s speeds. While this is constantly changing, when designing for the open web, you should always try to aim for the largest audience, while still cater for those outside that demographic - simply because the users are your mealticket.

There is nothing seductive about this "app" - there is no purpose, no clear goal, no need, and no usefulness.

 

The site loads here in under 20 seconds. core-i5.
And works without the bugs you all reported.

But since you're determined to keep up the insults, I'm gonna stop posting on this forum all together.

Good luck with your holier-than-thou attitudes.

 

You know, you forum regulars here could do better than making bullshit statements about me, i'm just a guy who comes in here to get some feedback on new web concepts i'm developing (like my menu). Instead of welcoming me and the experience I bring to this forum (see my thread on how to setup a web app, also met with much ridicule btw), you choose to insult my entire effort to the max, citing bugs that I've never seen in the wild before without any logging details or anything that helps me fix it (like a proper criticism in webdesign is supposed to go)...

You just lost yourself on this forum someone who could've helped you debug many a problem posted to this website.

But you regulars here are hell bent on keeping the web boring and ultra fast loading.

I have a much different view on webdesign. But rather than provide *constructive* criticism, you go on some sort of "mutant! mutant!" rant/rampage.

Seriously folks, good luck with your egos.

I'll see you in a couple of years when I've evicted most of the bugs from a feature-enriched version of this very same system i'm building now, and which you choose to insult as something from the past, claiming you can fix it in short order... hahaha... it took me 10 years just to get to this point, and you think you can do better in a week or something. Fools.

 

Wow. Just... wow. You.Are.Not.Listening.To.Critique!
We've all pointed to real-life reasons why this won't be useable in its current form. I'm happy to provide you with logs, screenshots etc. if that's what you want.
The statement that your site loads in 20 secs for you tells me only that you haven't done any real-world testing at all. Which doesn't mean it's not gonna work per se, but usually means there's gonna be a lot of stuff popping up. I'm assuming when you say it loads in 20 seconds, you're running it on localhost (or at least in a local network) - real life, external websites, doesn't work like that. The 1min (approx) load time we've described is not an exaggeration. It's real.
Besides, you're making bold statements about this framework, yet I've still not seen any list of features it's supposed to provide, which will revolutionize the web.

As for your other statements, you're way too thin-skinned to be on the web if our remarks brings you down - in all the comments, however harsh, we've given, you have been given a lot of constructive critizism as well. And if you've been to other forums, you've probably also gotten some of this from other venues - which should tell you something. We're not on this forum to be assholes, but our patience is very limited, and people not at all listening, or trying to improve, isn't worth our time.

You might be knowledgeable, I don't know about that, but from what I've seen thus far, you know absolutely nothing about design (I'm talking visual design here, I haven't dwelved into the code) - and you should perhaps listen a bit to people who's done this for a while.

And yes, of course we want the web to be ultra-fast loading. Given that users are prone to move on to a different site within 5 seconds of their entry, unless they find the content they're looking for, speed is king. Speed often involves simple, although not at all boring, design. There are quite heavy web-based solutions out there that loads quicker than yours, for instance online graphic processing packages, or Adobe's online colorpicker-solutions.

And seriously - if you've spent 10 years on a solution (to a non-existing problem), then perhaps you should realize it's time to move on, move forward? Most of us work with deadlines - 2 months, 3 months, a couple weeks. Within that time we need to present a working solution to a specific (or several specific) problem(s).

And, seriously, in a couple years? In a couple years, the web is gonna be completely different from now - new stuff keeps coming every day, things get improved, redone and forgotten. Will Facebook and Google still be around? More than likely. Will we be using the net in the same way as today? Probably not. Smaller devices (phones, tables, phablets and watches) are the new laptops. These devices have one major drawback - they're not fast. They're faster than computers were only a few years ago, but nowhere near what you need to drive that gargantuan beast you're working on.

What I would like to see, is a list. A list of things your product can do, that no other product can do. Or, at least do better than any other product.

 

Not seeing anyone doing that -- well, unless you mean my "delusion" comment.

Which I'm not understanding what's so "new" about abusing JS bloat to do CSS' job, mated to illegible colour contrasts, uselessly undersized fixed metric fonts, and fixed size background images. Even a javascript assist for the modern CSS3 approach would simply be nothing more than 15 lines trapping "click" and adding/removing classes; much less that it's a counterintuitive mess with things not opening/closing and overlapping willy-nilly so you can't tell what's what in ANY browser (see sarahk's screencap).

Excuse us for seeing a sub-40 post count user posting bloated slow laundry lists on how NOT to build a website and then not magically knowing what "experience" you have. If this is typical of your work and experience, you aren't going to be blowing anyone's skirt up.

Probably because it's wasting the fatass dumbass bloated jQuery bull (that I can't fathom how anyone would use in the first place) to do the job of MAYBE a class swap as a non-CSS3 fallback and a "input[radio]::selected>sibling" for modern browsers. What you have there is the WORST of pre-2000 scripting practices.

If you were unable to understand the criticisms given, you probably shouldn't be building a site; just what did you need clarification on?

I mean, inaccessible fixed metric fonts in the menu, illegible colour contrasts, painfully and agonizingly slow page loads, megabytes of scripting doing kilobyte's job, multiple scrollbars and perfect window size making it harder to use, said scrolling being jerky and so difficult to use nobody is going to want to even try to use the page.... what part of that do you need "logging info" on?

As to fixing it, for the most part I think all of us ripping it to shreds are pretty much telling you to toss that ENTIRE mess in the trash, back the groose away from the JavaScript for NOTHING, learn to use semantic markup with separation of presentation from content and build a website someone might actually want to try to use.

You posted a bloated slow wreck, but don't want to hear the truth, so naturally:

You run away and put your head in the sand. Good luck with that.

Why can't you make interesting and fast loading -- I think that's really the part I'm not getting about your page; hence PoP's asking for a list of what we're supposed to be impressed by and/or how to get to it... I'm not seeing ANYTHING that couldn't be done smoother/faster/more accessible without it. You mentioned WebGL -- where is that since I'm not seeing ANYTHING that would use it/need it! Even as the crappy perfect viewport page I'm not grasping what you are doing that needs that massive front-end logging garbage (likely to make people bounce) or EIGHT BLASTED MEGABYTES for. Unless it is broken in EVERY major browser (IE, Chrome, Opera 12, ChrOpera, Firefox) I'm just not seeing it!

Because it looks and behaves like something from the past... like late '97 early '98.

I wouldn't make that claim, I'd tell you what I tell a lot of people - throw it in the trash and start over; again using semantic markup, separation of presentation from content, progressive enhancement, letting flow and CSS do their jobs instead of diving for the "JS for nothing and your scripts for free. That ain't working, that's NOT how you do it"

Seriously, WHAT on that page are we supposed to be even the slightest impressed with and/or what is all that code even DOING? I don't see it! MAYBE you're seeing/doing something that isn't loading and/or doesn't run for EVERYONE else? Are you using some bleeding edge browser build nobody has installed yet or something? WHERE is the webGL stuff, WHAT is all that scripting supposed to be doing, WHY is the user interface so convolutedly scripted as to be unusable on one of the fastest CPU's Intel has ever released?

That your site created such a knee-jerk reaction from pretty much everyone here should be telling you something. But no, you don't want to listen... Have fun with your "let's throw more code at it" disaster.

Though for laughs, I make take a stab at doing a recreation of your layout (assuming I'm even seeing it properly) in HTML/CSS to try and show you what we are talking about -- and at the very least show you a better way of handling that menu that won't be jerky, slow and painful to use.

 

Ok, you people claim you don't want to be assholes, and more over: that all of your criticism is valid.

What you fail to note is that you didn't investigate what my system can do, how features are hidden by the menu (still under renewed development atm, so it didnt always work well), etc.

I can't help but laugh at people who say that all I do with my system can be redone in plain CSS3 in notime at all. There's many things CSS3 just won't do. the :hover class being ignored by plenty of browsers for plenty of HTML elements is one thing, ok..

So what *does* my system do, for all that code it downloads? oh, well:
- video backgrounds via youtube (not just pictures from the seductiveapps.com server)
- webgl backgrounds (3rd party)
- canvas backgrounds (3rd party)
- a background-selection system (via "View"->"New Background" menu) that works at the level of it's javascript interface like a google search query, to search among 12 thousand or more background pictures / content.
- the same menu system for background selection applies to any other content DIV as well (implemented for #siteContent right now only)
- auto generation of intermediate databases (in JSON, coz SQL sucks for web apps)
- a JSON database system (that works and scales to useable levels)
- semi-transparent backgrounds for text content, and offering a choice among many different background artwork PNGs through a dialog that's attached to each DIV containing text.
- loads most of it's code in the first page load (something that keeps debugging possible at all, due to limitations of Chrome) - once the page is loaded all subsequent requests are tiny.
- the ability to work on any screen resolution imaginable (ok, when it's a few months further down the line, it'll support small screens properly)
- the ability to (quickly, again via a menu and some javascript code(!)) select what content elements (main content, ads, music searchengine, etc) the end-user wants to see, then show only that content at next page loads.
- remembers (when i have that feature debugged again) the settings and artwork selected by the end-user, over what the page owner (could be a user of seductiveapps.com) has set.
- a youtube searchengine (for the builtin youtube player and as a background (yet to be re-debugged))
- a menu with crossfades of video fragments for 4 different menu-item states (normal, hover, selected, disabled) and crossfades between video fragments when the state of the menu-item changes.
- soon-ish : a menu that can browse huge and deep menus on even small screens without the user getting lost in the menu.

and yes, building all this (which i dare call innovations for webdesign) took me 10 years and about 6 or 7 complete rewrites. I'm not shy of rewrites, so long as they improve my system.

now, to get to your indeed important criticism: "wheeeee it loads too slow" - lemme explain 5 factors:
- PC speed is still increasing each year, so is smartphone speed. Furthermore, there's a tendency to do some things (like mixing opacity from PNGs for instance) in dedicated chips sooner or later, making some operations "suddenly" very fast where they once were slow as F..
- the area i live in (i serve seductiveapps.com from home, currently a 280kb/s adsl line) is bound to get fiber internet one day within the next 10 years.
- i'm in regular contact with a dude who is writing a jQuery like system to facilitate recursive lazy-loading of javascripts (and more). but it's pointless to include his system for lazyloading before that's properly debugged, has stood the test of not-selling-out (which i think the dude has every right to btw)
- i already have a vulcanization script, a concatenation PHP script for all of my javascripts, ready. That'll bring down 70+ javascripts in <head> to just 1. It can be plugged in quickly, but currently break's Chrome's ability to debug my code.
- i have started work on, but haven't properly debugged yet, a waiting queue for my website, ensuring that if 2 visitors arrive at the same time, they're served the page one-at-a-time.

So people, before you seriously diss a website that loads up a lot of code, at least try to figure out what is done for all that code. Code hardly ever gets written without doing something, mkay..

 

Now can we move this discussion back to my menu please?