28 ms·

Designers loved Flash because it was WYSIWYG. It's also why PDF lives. You usually only had to test it on one computer, not different versions of different brow

• jagged-chisel 7y ago
  I'm not a web front-end dev, so pardon my ignorance ... Would a canvas and/or SVG GUI be acceptable?
  • tabtab 7y ago
    I haven't seen it work well. Part of the problem is that JavaScript is needed emulate many common GUI idioms, and the emulation or rendering is sometimes buggy on different browsers. It's back the the brand/version combinatorial explosion. The industry really needs a dedicated GUI-friendly standard. Emulating GUI's keeps failing. If you fail 30 beauty contests, the blunt truth is you are ugly. Get a clue and change direction.
    • brians 7y ago
      This is called “forms”. The people who are failing to do better do care—they just also see the limits of the work.
    • arxpoetica 7y ago
      There's hope. If you look at the GUI for Figma (an Illustrator and Sketch vector drawing competitor), they've built it using the Canvas tag...and it works AMAZINGLY well. I don't know how they did it, but it feels more like butter than Sketch, and I love Sketch. I'm waiting for someone to come along and basically build the Flash equivalent of a canvas tag renderer. But it's going to take some serious smarts. There is some precedence. Rich Harris (of Rollup & Svelte fame) has been toying with the idea of a precompiler for Web GL...
  • Tobani 7y ago
    Context matters. If you're building essentially square box with interactions (essentially flash) , it would probably be fine. But if you're trying to optimize across several displays HTML can re-flow for you and isn't generally terrible unless you're doing things that need to be pixel-perfect.
    • tabtab 7y ago
      I believe we need 3 different UI standards: 1. Page and document centric (HTML may be close enough) 2. Productivity and data-oriented GUI's ("cubicle" stuff) 3. Games, art, and diagrams Doing everything in HTML/CS/JS keeps proving too clunky. Even the big wealthy sites have odd rendering bugs that pop up.
      • Tobani 7y ago
        > Doing everything in HTML/CS/JS keeps proving too clunky. Clunky, sometimes sure. It has largely been fine in my experience. > Even the big wealthy sites have odd rendering bugs that pop up. This will always be the case.
        • tabtab 7y ago
          Re: It has largely been fine in my experience. That's not my experience. It requires too much fiddling and diddling to get things right that wouldn't be drama under 90's GUI IDE's. (Early versions sucked, but they got better with time.) Maybe a few experts somehow master all the arcane CSS/DOM rules, but that's the exception. Arcane fiddling may be great job security, but it's not economically logical on a planet-wide view.
  • shadowgovt 7y ago
    Doing it with canvas / svg is a bit like saying you can do a videogame because you have access to webgl and web audio API. In the most technical sense, yes, but it's way too low level an abstraction to be practical. Flash's entrypoint abstraction was the timeline, which already bundles up a huge amount of complexity around time-based transformation of content that you'd have to build atop canvas to approach Flash's convenience.
• dleslie 7y ago
  In terms of predictable layout and control, Flash is still lightyears beyond HTML+JS; and that's nothing short of a catastrophic failure on the part of browsers. That said, Flash was/is an accessibility nightmare. It broke screen readers, and the animations and custom interfaces regularly created unnecessary cognitive load and confusion.
  • airza 7y ago
    I don't think that it's particularly difficult to make extremely predictable layouts in HTML+JS if you have the same constraints as flash (particularly a fixed canvas size).
    • dleslie 7y ago
      In Flash it could be done in minutes, with no prior experience, and only using a mouse.
      • VMG 7y ago
        ...and the closed, proprietary authoring tool
        • dleslie 7y ago
          That was widely available to huge numbers of designers who already had Adobe's Creative Suite, whether through work or school or from the high seas.
        • Google234 7y ago
          There's nothing wrong with using proprietary software. Sometimes it's good to support developers.
          • xtracto 7y ago
            This has been a very interesting change in Hacker News. Back in 2010 when I first learned about it, I was coming from Slashdot. And for me it was a (refreshing) surprise that people here were not anti-paid software, anti-business, etc. After all, it is a forum within a VC firm that looks to fund startups to make a profit. The discussion was more pragmatic. Somehow nowadays the group think has kind of changed into what Slashdot was 10 years ago. Which is funny, since the objective of YC has not changed.
• okcando 7y ago
  This is nearly the opposite of what I would want from HTML or the web. A fixed layout is not going to work for all devices. Such a choice is tantamount to deciding that some classes of devices are not going to be supported, which may be a reasonable choice but better to make good choices in the HTML and CSS and let the devices try to make something usable of it rather than giving them a fixed window into a layout intended for another.
  • buboard 7y ago
    > A fixed layout is not going to work for all devices. Designers are also making their choice with HTML nowadays : Desktop is not supported anymore. Look e.g. at twitter, a billion dollars company switching to mobile web only. Flash could easily implement media queries to re-layout itself.
    • Ajedi32 7y ago
      > Look e.g. at twitter, a billion dollars company switching to mobile web only Source? Twitter.com currently works just fine on Desktop. Even dynamically adjusts its layout to look good on a bunch of different screen sizes.
      • buboard 7y ago
        Just by the padding in the buttons it's obvious that twitter's current site was built for mobile. Sure, it's responsive, and i bet flash could become responsive if it was still alive. HTML games however are also non-responsive most of the time just due to the nature of their use case.
      • altec3 7y ago
        They might have meant mobile-first and not mobile only. Their desktop site is very clearly designed for mobile, the main content does not change at varying screen widths. The sidebar and header do a bit of restyling, but thats about it.
      • steveklabnik 7y ago
• buboard 7y ago
  HTML has <canvas> now. Flash is essentially no different than that , except for the security holes, which are not unfixable. The other HTML equivalents of it are just too heavy resource hogs, including video players.
  • justinator 7y ago
    What made Flash AMAZING was its authoring environment. Scripted multimedia content (via SWF) I could run and share in the browser in 1998! The first time I ever bought software was Flash 4. Watching, then sharing animations probably caused me to go to Art school. It was incredibly impressive stuff back then. I just to make or consume that sort of content anymore though. I couldn't even tell you how to do it using HTML, or how to author it. Speaking of school, <aside>I remember when I signed up for a Director course (Director!), and it was re-done into an advanced internet art class, and all I did was hand in HTML/Javascript assignments. I failed the class, as I worked on all that stuff during my job, the teacher didn't know anything about the tech, and I was inundated with questions on how to do cool stuff. </aside>
    • buboard 7y ago
      It got to the point where it was too annoying to visit all those different websites with animated intros, weird menus, sounds etc. It was like 1000000 cdroms on the browser. But yeah, thanks to 20 years of progress we can now stare at 1000000000 identical bootstrap homepages.
      • justinator 7y ago
        At the time, I remember being pretty OK with taking the terrible with the good - it all felt like experimenting to me, and I gravitated towards more of the designer-y/artsy sites, rather than the games and cartoons. This was back when David Carson was highly influential designer (for good or ill), and I was coming from skateboarding/snowboarding culture, which (and I sound so old) was a lot different, 20 years ago. Like it was COOL to be really into Typography, and the messier, the better. Because, "The 90's" I guess.
      • 7y ago
• shadowgovt 7y ago
  WYSIWYG mode, unfortunately, ignores the needs of screen readers and other methods of accessing content. The risk of WYSIWYG tools is they lie to you; not all your users can actually see what you see. And that's to say nothing of the less exotic scenarios like different screen sizes or devices. ... unless you're working in a space allowed to discriminate against users that need assistive access to your content of course, in which case you can spring for the WYSIWYG dream.
  • tzjmetron 7y ago
    . allowed to discriminate against users What a cunt you are!
  • Wowfunhappy 7y ago
    If screen reader accessibility was the only thing holding us back from a WYSIWYG dream, I would advocate just maintaining separate content-only versions of all pages. I don't think that's actually where we are though. As you touch on, code is inherently necessary in order to build responsive pages. A static layout will never know how to reflow itself when the window size changes; it needs code to define that behavior.
    • chrisweekly 7y ago
      >"A static layout will never know how to reflow itself when the window size changes; it needs code to define that behavior." I know what you mean wrt fixed-width layouts, but want to point out that reflow is the default browser behavior in the absence of problematic markup and styling rules. That's the beauty of mobile-first RWD and progressive enhancement when done right; the starting point is just the content, full stop. The first media query is the absence of support for media queries. Then min-width rules to guide layout changes across progressively larger breakpoints.
    • inetknght 7y ago
      Changing the layout of a page just because the window was resized is moronic.
• jml7c5 7y ago
  >It's also why PDF lives. PDF lives because it's ubiquitous and stable, despite really rough tooling. If you don't have Acrobat it's a bit of a nightmare to work with, simply because it's so opaque. Yes, you can decompress a PDF to text and look through it by hand, but you need to learn the syntax and know how to use an extensible text editor with the write add-ons; this isn't something your average person in an office will know how to do. The lack of discoverability is evidenced by the number of posts on Stackexchange etc. that answer "how do I losslessly recompress a PDF?" by giving a command that actually performs lossy downsampling. Or the accidental inclusion of secret layers underneath what were supposed to be blackout redactions. Personally, it took me ages to figure out how to losslessly recompress a monochrome image using JBIG2, which provided an enormous space savings and should have been much easier with some tree-based GUI explorer. I'm hoping that one day we'll get a good, stable, powerful, reflowable PDF-like format. HTML+CSS+JavaScript works, but it's a huge standard, rendering is not exact, performance (in terms of memory usage in particular) isn't great, it's best created by hand (requiring programming and/or technical knowledge), and it's not really self-contained or sandboxed from network access.
  • jl6 7y ago
    To this excellent defence of PDF I would like to add that it works perfectly well offline and, crucially, is just a plain old file that can be emailed, WhatsApp’d, backed up, etc. without anyone’s permission or any ongoing dependency on centrally managed servers. My next website project will be published in PDF, not HTML.
    • qu4z-2 7y ago
      HTML also works perfectly well offline, though, if you don't reference online assets. And if your objection is that it can run JavaScript and make web requests, then I have some bad news for you about PDFs.
      • malka 7y ago
        the problem with html is that it's hard to pack it in a single file like a pdf.
• vortico 7y ago
  You can have WYSIWYG with HTML. You just have to use pixel values for everything and assume some fixed pixel width of your application. Flash can rescale also, but it runs into the same layout/rescaling problems as you do with HTML.
  • beernutz 7y ago
    This is just not true. you did not have to specify fixed width in flash any more than you do with HTML. Flash's approach used something like a constraint solver to allow some areas to grow and some areas to have anchor points. It was reactive by design.
    • tabtab 7y ago
      I think the key is that what the browser (client) gets should be coordinates. If the server side wants to use some wazoo auto-layout engine, that's fine. And that gives one a wide choice of layout engines/algorithms, unlike browsers. Yes, browsers do have different layout engines available, but they all go through buggy and inconsistent JavaScript and CSS in the end: the chain is as strong as the weakest link.
  • tabtab 7y ago
    Doesn't work well for text in my experience. Perhaps a bounding box can be defined as pixel coordinates, but there's no guarantee the text will fit right across browser brands or versions.
• devit 7y ago
  You are supposed to design your UI based on general principles ("three vertical blocks", "list of elements with a label", "text with paragraphs", etc.) and let the user agent lay it out as it wants and accept whatever result happens, and not attempt to test or micromanage it to get a preconceived result. At any rate, HTML layout is determined by the spec barring rare bugs, so you can design something that lays out exactly how you want regardless of browser, except that you must decide and specify the layout for any possible width/height combination.
• BubRoss 7y ago
  Layout isn't rocket science until someone makes it more complicated than it needs to be. I don't remember flash being very adaptive to different resolutions.
  • beernutz 7y ago
    Flash's approach used something like a constraint solver to allow some areas to grow and some areas to have anchor points. It was reactive by design.
    • BubRoss 7y ago
      Sounds like tables with a mix of absolute and relative sizes. This isn't 'reactive by design' this is how basic computer UIs have worked for decades.
• jdietrich 7y ago
  What you see might be what you get, but it's not what I get, for reasons that are innate to the web. My mother still uses an iPhone SE with a 4.7" screen, while I use a gargantuan phablet. My grandmother has poor eyesight and runs her browser on a 720p screen at 175% zoom, while I have a large high-resolution monitor and normally open browser windows to 1280x2160 portrait. My monitor is color-calibrated and extremely bright during the day, but after sunset it's deep amber and very dim. If you think that WYSIWYG for the web is desirable, you haven't understood the web.
  • beernutz 7y ago
    Wasn't he talking about a "special mode" for places where WYSIWIG might be the better case? Not for ALL content, but for some web applications (complex CRUD apps maybe as a good example) I feel like there is still very much a case to be made for this. Maybe the form it takes would be a good place for discussion, but really there is no reason things like this have to be inaccessable to screen readers any more than a native app would be.
• bborud 7y ago
  > Designers loved Flash because it was WYSIWYG. I hate designers who think they are typographers. Typography is an engineering discipline. It is not something you want to leave to designers. Especially not insecure designers (and customers) who need constant novelty. Computers are not paper. Get over it and adapt.
  • gabos 7y ago
    Most graphic designers are typographers, by definition of the word. The move from print to screen hasn't changed that.
    • redwall_hp 7y ago
      LaTeX makes them obsolete in either case.
      • watersb 7y ago
        When web browsers support LaTeX-like hyphenation and justification with microtypography (tiny tweaks to the tracking tightness), then I will be obsolete and happy. I would accept less than 60 frames per second.
    • bborud 7y ago
      No, they are not. Thinking they are does not make it so and it just leads to poor typesetting. The typographers I know typically have a BA from an engineering college. The advent of desktop publishing and later other forms of electronic publishing has hollowed out the field.
• nneonneo 7y ago
  > I believe Flash and Java Applets both made the same fatal mistake: tried to be an entire virtual OS. That made them too complicated, which invites hackers. Let’s be fair here: every major web browser also implements an entire virtual OS by this metric, probably even moreso than Java or Flash ever did. Yes, they absolutely do invite hackers with their absurdly complex designs, but advances in security-in-depth have made them fairly hard targets (not invulnerable, though, as Pwn2Own demonstrates annually). Flash and Java never really had enough attention paid to real, in-depth security engineering by comparison, and browsers learned from those lessons and improved. The JavaScript engine and API scope in a modern browser is easily multiples of what you could access from ActionScript in Flash, but the security is much better.
• bsder 7y ago
  > A few snotty Sheldons mastering auto-flow math doesn't scale well. How about we quit ignoring the elephant in the room? CSS sucks. It was designed for a time when Javascript wasn't required for every website. Now that we've thrown in the towel and every single website is dependent upon Javascript, we should toss CSS, too.
• tracker1 7y ago
  Having worked on content in eLearning while Flash was king, it was far from a panacea. Especially for government related training content. Almost everything was meant to be run full-screen at 1024x768. Can you imagine if everything were still VHS quality today for video? In the end, technology moves forward. And frankly, there are enough libraries for grid/layout that really close to just work. I find that material-ui with react is insanely easy to use compared to what came before. Every time I do anything more custom, yeah, I have to google it and play around witht he CSS rules. However, for CRUD guis, material-ui library all the way. In the end, you aren't going to get away with knowing nothing. Even in the Flash days, if you wanted to do anything interesting you had to know ActionScript and the quirks that went with it. For forms and crud apps, you had Flex, which had its' own niceties but wasn't a panacea either and wasn't WYSIWYG either. What could have saved Flash was opening the runtime and creating an interoperable specification and let browser vendors work with Adobe (Macromedia and I forget the company before that) etc. Silverlight was much closer, but still sucked in a lot of ways that held it back in the end. Flash's tooling still exists and iirc targets HTML5 these days, so you can still pay and use it. If Flash had simply been a bundle spec for a zip archive with a manifest file, JS, SVG and MP3 (or other audio) and video files it could still be a thing. I had hoped that would be the direction it would go when Adobe bought Macromedia. It wasn't. It was the source of too many bugs and crashes and it died because of it.
• jeffdavis 7y ago
  There is tension between two fundamental ideas: is the server offering content and allowing the client to interpret it as they see fit; or is the server offering an experience that is out of the hands of the user? Out of these two conflicting ideas come all sorts of issues. Accessibility is one, but so are things like scraping, copy/paste, DRM, confidentiality, artistic integrity, cross-platform compatibility, new devices, peformance & resource consumption, etc.
  • tabtab 7y ago
    Agreed, but web standards don't support the second choice very well. Different groups, scenarios, or apps will want one or the other depending on circumstances, but we don't have "other" right now. The server having more control doesn't necessarily harm accessibility. It's a matter of making sure sufficient meta-data is included. It's possible accessibility is more work under the second, but not outright impossible. (I've stated more about accessibility nearby.)
• jpochtar 7y ago
  I worked on a WYSIWYG HTML editor (Pagedraw) for a while, and came to the conclusion it's overkill for the problem of browser layout. For CRUD apps, you really just want HStacks, VStacks, and ZStacks like they have in SwiftUI. They nicely express reflow behavior without driving you crazy or bloating your code. They're a bit more work than drag-and-drop because they make you be explicit about resizing/reflow, but you should be thinking about that anyway. You'll want to skip that step when iterating quickly on design, but that's why you design in a separate design tool, which is visual and uses position:absolute. When you're ready to parameterize the design over varying content and screen sizes you'll have to specify resizing constraints somehow, and in my experience, VStacks/HStacks in code are a pretty good way to do it. I recommend adding building these abstractions on top of flexbox, and adding them to your standard library. This is all specifically for CRUD apps. If you're making an animation, or something else that would feel wrong to call a "document", you probably want a completely different set of tools.
• hollerith 7y ago
  In other words, designers want to control my experience, which conflicts with my desire to control my own experience. If the "designer" of a web page were able to send me plain text and links only, with my client application in control of the font, size, line width, layout, etc, I would prefer that to current state of the web.