HTML5 Audio — The State of Play | HTML5 Doctor
8 views
Skip to first unread message
Owen Densmore
May 16, 2012, 11:30:51 AM5/16/12
to dis...@sfcomplex.org
This week's HTML5 Weekly points to a great html5 audio survey: http://goo.gl/6GOke
The site, http://html5doctor.com/ is a great overall reference and article site too.
And for html lazy folks, there is a pointer to a "html boilerplate" generator:
.. and its much more "industrial strength" (but possible over-kill) brother:
Basically these create "empty" html/css for you to start your page with.
-- Owen
Joshua Thorp
May 16, 2012, 12:46:52 PM5/16/12
to dis...@sfcomplex.org
Why lazy? There is just so much crap that you have to get right to make HTML5 work it totally makes sense. I think html5boilerplate is great and I see a lot of people using it.
Cool! htmlshell looks like a nice way to document what those pieces do.
--joshua
For extra points check out the latest app boilerplate: http://html9responsiveboilerstrapjs.com/
--
You received this message because you are subscribed to the Santa Fe Complex "discuss" group.
To post to this group, send email to dis...@sfcomplex.org
To unsubscribe from this group, send email to
discuss+u...@sfcomplex.org
For more options, visit this group at
http://groups.google.com/a/sfcomplex.org/group/discuss
Owen Densmore
May 16, 2012, 1:24:04 PM5/16/12
to dis...@sfcomplex.org
That's so funny *and* cool its probably not legal!
I note the use of "Responsive". Basically how do you build a website or webapp that can be used on phones, tablets, desktops, TVs etc. Responsive to the device being used to view the page/app.
I didn't know about that concept before this weeks HTML5 Weekly .. a pointer to building "responsive pictures" and its controversy. I headed over to A List Apart to get the skinny and it does look doable.
So I guess the boilerplate world can help do this?
-- Owen
Owen Densmore
May 16, 2012, 1:37:05 PM5/16/12
to dis...@sfcomplex.org
Oh, and it also passed the Turing Test. Wow!
-- Owen
Joshua Thorp
May 16, 2012, 1:51:06 PM5/16/12
to dis...@sfcomplex.org
Yes, it seems like the present in computing has a lot of boilerplate in it. And the frameworks are trying (to various levels of success) to ease the pain of boilerplate stuff.
For instance I do a lot of tempting with Django. I have an index.html that has the boilerplate in it, and all my pages just plug into this, so when I make a new page I really am only concerned with a couple of variables maybe just title and content… So I don't even see the boilerplate day to day.
Thats why I like python, basically remove as much clutter as possible and get down to the interesting bits of logic that set this particular thing apart from other things. To use the technical terms.
--joshua
Chad Kieffer
May 16, 2012, 5:47:28 PM5/16/12
to dis...@sfcomplex.org
As a developer who was trained as a graphic designer, I love seeing the discipline once known as web design taking a few pages out of the software engineer's playbook. Now they're called front-end engineers and they're creating libraries and defining patterns to quickly and reliably create interfaces that work.
It's a win-win! Like Joshua points out, these tools let developers and designers focus more time on the unique aspects of each project.
Bravo!
- Chad
Owen Densmore
May 16, 2012, 6:51:55 PM5/16/12
to dis...@sfcomplex.org
On Wed, May 16, 2012 at 3:47 PM, Chad Kieffer <ckie...@gmail.com> wrote:
As a developer who was trained as a graphic designer, I love seeing the discipline once known as web design taking a few pages out of the software engineer's playbook. Now they're called front-end engineers and they're creating libraries and defining patterns to quickly and reliably create interfaces that work.It's a win-win! Like Joshua points out, these tools let developers and designers focus more time on the unique aspects of each project.Bravo!- Chad
As someone interested in both how folks learn and the evolution of computing, I'd love to hear more! Could you give us a bit of a story how you made the transition(s)?
A similar surprise for me as a programmer who started in the 70's, is the evolution of "gamers" into programmers.
I've followed A List Apart for years, and am amazed to hear their seamless transitions back and forth between design, web standards, and programming. These are the folks who brought us CSS as they struggled to separate content from "looks". They also tend away from CMSs which often turn out rather poor HTML/CSS. I have a great deal of respect for this sophisticated crowd and hope it grows.
-- Owen
Chuck Baldwin
May 16, 2012, 8:30:49 PM5/16/12
to dis...@sfcomplex.org
I feel I am intruding on this conversation. But... I started out developing sites using the stoopid software Iguana page editor because (besides being a freebie) it had a split screen and when I placed a table in the gui I saw the code appear on the other side of the screen. Which is how I learned html along with the htmlgoodies website. I still use page techniques that still work from those days, like getting rid of <div> tags because they notoriously seem to also drop an nbsp tag inside of themselves and create issues with dropping graphics into tables (probably an outdated dreamweaver issue).
I often wish for a perl editor (and any language editor) that acted the same way. My learning is very much tied to seeing it, and writing it. Then I seem to know it. And understand what functionality goes with that set of code. And can build flow out of it easily as a result.
What is also interesting to me about that early Iguana editor was then seeing the evolution of html, and my having to adapt to the new changes. Often I would have ideas that seemed to arrive with the next level of html, like wouldn't it be cool to have transparency and non-transparency of tables with tables nested inside of other tables, and then suddenly one year, there it was.
I believe, with such a set of editors described above, I'd be developing lots of different things. It is annoying to me to have to invoke the source command to see what the code is doing, as I didn't put the code there a piece at a time, and then simultaneously get to view what that same code achieves, and see the blocks build into something that works, and then fundamentally understand what the ensuing flow resulted in.
Learning to embed video drove me crazy because everyone seemed to come up with code that did it in various ways. I've seen at least eight varieties of ways to do that, if not more, and while I know enough to understand what each variation seems to be achieving, I can't help wishing for one way to keep showing itself, thus getting to a kind of standardized way to achieve the end. That may be bland thinking but it'd make life a little more efficient. Of course that whole world is in the midst of change now, so my comment is moot. fwiw
-C
--
Chuck Baldwin
May 17, 2012, 5:51:17 AM5/17/12
to SFx Discuss
Maybe my complaint below is a lead onto something else. You more
serious coders might think small of this but it strikes me that if I
had a perl editor that somehow created a visual semiotic, a sign,
perhaps derived from a flowchart, similar to the Iguana editor, where
I pick a gui object like a table, but in this case let's say I want to
send a set of data out to an xml function and have it turned into a
nice looking printed page, if I could see a sign or symbol in an
editor that told me that was what I could choose, drop that into a
split screen editor and see the code arrive on the other side, I'd
suddenly be in a position to have the understanding of what the perl
code was doing, and hence be, albeit at somewhat of a distance, able
to "read" the code.
Such an editor for python, perl, php, etc...
I'd be on fire.
And similarly, semiotic assignments to libraries and the various
routines that can be pulled from those...
see where I'm going with this? It is taking it from the code to the
visual, but by having a split screen one can develop an understanding
of what the code is doing by having visual cues.
Dare I say it? A feedback loop.
ow
-C
On May 16, 8:30 pm, Chuck Baldwin <crystalcityacade...@gmail.com>
wrote:
> On Wed, May 16, 2012 at 6:51 PM, Owen Densmore <o...@backspaces.net> wrote:
> > To post to this group, send email to disc...@sfcomplex.org
serious coders might think small of this but it strikes me that if I
had a perl editor that somehow created a visual semiotic, a sign,
perhaps derived from a flowchart, similar to the Iguana editor, where
I pick a gui object like a table, but in this case let's say I want to
send a set of data out to an xml function and have it turned into a
nice looking printed page, if I could see a sign or symbol in an
editor that told me that was what I could choose, drop that into a
split screen editor and see the code arrive on the other side, I'd
suddenly be in a position to have the understanding of what the perl
code was doing, and hence be, albeit at somewhat of a distance, able
to "read" the code.
Such an editor for python, perl, php, etc...
I'd be on fire.
And similarly, semiotic assignments to libraries and the various
routines that can be pulled from those...
see where I'm going with this? It is taking it from the code to the
visual, but by having a split screen one can develop an understanding
of what the code is doing by having visual cues.
Dare I say it? A feedback loop.
ow
-C
On May 16, 8:30 pm, Chuck Baldwin <crystalcityacade...@gmail.com>
wrote:
> > To unsubscribe from this group, send email to
> > discuss+unsubscr...@sfcomplex.org
Chuck Baldwin
May 17, 2012, 6:17:59 AM5/17/12
to SFx Discuss
Sorry to ramble,
Dreamweaver sort of attempts to do this, but it's sloppy imo. All of
the options all along the path of programming a page are all available
all the time.
I think that somehow the various (sorry to use a microsoft term here)
"ribbons" dreamweaver and other editors make available, can overwhelm
the user, it does to me anyway.
In game fashion, if a door were to open, a set of ribbons that have
true contributing functionality to that stage of a page design or
other end product, and a door were to close once something was dropped
onto an editor, meaning new ribbons become available and others shut
off, one would be guided by the editor in directions that "work", and
wouldn't be wasting time trying brute force iterations of clickable
choices from a near infinite pallette to put on a page that ultimately
won't function once sent to a live run.
Bringing editing closer to the likes of myself.
And within each set of ribbons the user/coder/developer can thus dwell
on what the power of each ribbon brings to that closed set of
functionality, and thus tweak happily, finding the results of their
tweak quickly as a visual result.
> On Wed, May 16, 2012 at 6:51 PM, Owen Densmore <o...@backspaces.net> wrote:
> > To post to this group, send email to disc...@sfcomplex.org
Dreamweaver sort of attempts to do this, but it's sloppy imo. All of
the options all along the path of programming a page are all available
all the time.
I think that somehow the various (sorry to use a microsoft term here)
"ribbons" dreamweaver and other editors make available, can overwhelm
the user, it does to me anyway.
In game fashion, if a door were to open, a set of ribbons that have
true contributing functionality to that stage of a page design or
other end product, and a door were to close once something was dropped
onto an editor, meaning new ribbons become available and others shut
off, one would be guided by the editor in directions that "work", and
wouldn't be wasting time trying brute force iterations of clickable
choices from a near infinite pallette to put on a page that ultimately
won't function once sent to a live run.
Bringing editing closer to the likes of myself.
And within each set of ribbons the user/coder/developer can thus dwell
on what the power of each ribbon brings to that closed set of
functionality, and thus tweak happily, finding the results of their
tweak quickly as a visual result.
> > To unsubscribe from this group, send email to
> > discuss+unsubscr...@sfcomplex.org
Chad Kieffer
May 18, 2012, 3:07:59 AM5/18/12
to dis...@sfcomplex.org
I'd say the following factors played a role in my transition:
- Being hired on at LANL, right out of college. I attended my first HTML class, an in-house course, in '95. There was a lot of demand for web sites at the Lab. The Lab offered a generous individual training budget and I was working on web and print design projects for LANL technical staff members, a few of whom became mentors. Although I hated having to use CVS to publish pages for the Advanced Computing Lab's site, I couldn't live without Subversion or Git today.
- Tiring of managing content for web site owners. More and more of my time was being eaten up crossing t's and dotting i's for others. So I starter tinkering with Perl to build simple aggregators.
- Embracing the DRY principal. A coworker introduced me to Apache's server-side includes feature. That changed how I approached everything afterwards, from CSS to PHP.
- The release of OS X. I had done some interesting things in Perl and had written a simple ASP-based CMS, and then Apple released OS X. Forget about writing VB Scripts and FTP'ing them to a remote IIS Server! With OS X I could now set up a complete local development environment. Yeah, compiling Apache, PHP, and their dependencies wasn't easy at first, but there were some great tutorials (Wincent Colaiuta, wincent.com) and package installers became available soon after (Marc Liyanage, www.entropy.ch).
- Volunteering time to an open source project. I used the Gallery photo manager (gallery.menalto.com) to build a family photo album and an art gallery web site. I contributed a small donation and an offer to help the project with their UI design, if they needed help. A few days later I started hanging out with the project members on IRC. I started hacking away on themes at first and then a module or two. Other project members, developers at Google and Sun among them, were awesome to work with and helped me to learn a lot about software development teams and processes.
- Teaching web development courses. I spent a few years at LANL teaching HTML, CSS, and PHP courses. This helped me step back and examine these subjects in more depth. If you think you're an expert on something now, I challenge you to teach it to others.
Maybe I'll write a bit more about this sometime.
- Chad
Chad Kieffer
May 18, 2012, 2:14:13 PM5/18/12
to dis...@sfcomplex.org, SFx Discuss
Chuck, if you haven't tried it, give the Firebug plugin for Firefox a try. It's an excellent debugging tool and allows you to inspect page elements through a split pane UI, like what you've described.
After installing and enabling, right-click on a page element and select "Inspect element." You'll see a split pane at the bottom of the window showing HTML markup and CSS for the element you've selected.
- Chad
> To post to this group, send email to dis...@sfcomplex.org
After installing and enabling, right-click on a page element and select "Inspect element." You'll see a split pane at the bottom of the window showing HTML markup and CSS for the element you've selected.
- Chad
> To unsubscribe from this group, send email to
> discuss+u...@sfcomplex.org
Chuck Baldwin
May 19, 2012, 9:00:44 AM5/19/12
to SFx Discuss
Hi Chad, The same tool is available in Chrome, I have used it a few
times already. It's a good start but my next level thinking tells me,
wouldn't it be great if that split screen ability also took you into
an editor, with a ribbon for that specific section of code that gave
you all of the available options for that particular chunk of code,
and did so in a follow-this-path kind of thinking. It'd be a mind
boggling affair to program such an editor because permutations could
expand dramatically from any chunk of code. But I see that as an
ideal. Current editors kind of get there but are somehow overly
complicated in pallette instead of being a one foot in front of the
next kind of thinking.
I think I kind of need to re-cap something from my recent studies in
Visual Literacy and Information Design.
I would challenge the programmers who love to be deep in code to
convert that code to representative imagery. Can you do it? And for
those of you that teach, implement such a set of married code and
symbols as part of your teaching plan and see (ow) what happens.
Dan Roam is on Moyra Gunn's TechNation at the moment. Dan Roam's book
"The Back of the Napkin" was a required read. In Visual Lit we have
Asa Berger (I think that's the author) pounding it into our heads that
words, text, CODE, alone may not make the trip to the learning center
of the mind. It is when BOTH image and text, or image and code,
finally get to the brain and seem to settle in.
Moyra's show today is very good.
Dan has a new website, www.napkinacademy.com , he shows his graphical,
textual thinking there pretty much as it is in his book.
My point in my 3 part ramble above, that I kind of didn't tie off to,
is this tie between code text and getting the code text married to a
visual. By putting those two together we symbiotically enrich the
conveyed message to become real brain food the mind can gnash on and
imbibe. It brings those of you who code textually and those of us that
need the visual impact together like the octagonal stop sign and its
red coloration does. One part of the stop sign is color and shape, the
other is the enlarged text. Which brings about a tertiary result, we
hit the brake or most do anyway.
-C
On May 18, 2:14 pm, Chad Kieffer <ckief...@gmail.com> wrote:
> Chuck, if you haven't tried it, give the Firebug plugin for Firefox a try. It's an excellent debugging tool and allows you to inspect page elements through a split pane UI, like what you've described.
>
> After installing and enabling, right-click on a page element and select "Inspect element." You'll see a split pane at the bottom of the window showing HTML markup and CSS for the element you've selected.
>
> - Chad
>
times already. It's a good start but my next level thinking tells me,
wouldn't it be great if that split screen ability also took you into
an editor, with a ribbon for that specific section of code that gave
you all of the available options for that particular chunk of code,
and did so in a follow-this-path kind of thinking. It'd be a mind
boggling affair to program such an editor because permutations could
expand dramatically from any chunk of code. But I see that as an
ideal. Current editors kind of get there but are somehow overly
complicated in pallette instead of being a one foot in front of the
next kind of thinking.
I think I kind of need to re-cap something from my recent studies in
Visual Literacy and Information Design.
I would challenge the programmers who love to be deep in code to
convert that code to representative imagery. Can you do it? And for
those of you that teach, implement such a set of married code and
symbols as part of your teaching plan and see (ow) what happens.
Dan Roam is on Moyra Gunn's TechNation at the moment. Dan Roam's book
"The Back of the Napkin" was a required read. In Visual Lit we have
Asa Berger (I think that's the author) pounding it into our heads that
words, text, CODE, alone may not make the trip to the learning center
of the mind. It is when BOTH image and text, or image and code,
finally get to the brain and seem to settle in.
Moyra's show today is very good.
Dan has a new website, www.napkinacademy.com , he shows his graphical,
textual thinking there pretty much as it is in his book.
My point in my 3 part ramble above, that I kind of didn't tie off to,
is this tie between code text and getting the code text married to a
visual. By putting those two together we symbiotically enrich the
conveyed message to become real brain food the mind can gnash on and
imbibe. It brings those of you who code textually and those of us that
need the visual impact together like the octagonal stop sign and its
red coloration does. One part of the stop sign is color and shape, the
other is the enlarged text. Which brings about a tertiary result, we
hit the brake or most do anyway.
-C
On May 18, 2:14 pm, Chad Kieffer <ckief...@gmail.com> wrote:
> Chuck, if you haven't tried it, give the Firebug plugin for Firefox a try. It's an excellent debugging tool and allows you to inspect page elements through a split pane UI, like what you've described.
>
> After installing and enabling, right-click on a page element and select "Inspect element." You'll see a split pane at the bottom of the window showing HTML markup and CSS for the element you've selected.
>
> - Chad
>
Reply all
Reply to author
Forward
0 new messages