Domain: b-list.org
Stories and comments across the archive that link to b-list.org.
Comments · 8
-
Re:Can technology aid journalism?
I actually work tech at a big media organization, so this is something I think about constantly, and the article is a perfect example of the media missing the goddamn point.
I actually work tech at a small media corporation, and getting the rest of the industry to wake up is something we've been trying to do for years now. I'm employed by the company which (among other things), publishes the Lawrence Journal-World, of Lawrence, Kansas. Most folks, if they know who we are at all, know us as the original home of the Django web framework, but Django came out of our need to quickly put together custom applications for our online presence, something we've historically done as well as or better than anybody else in the industry.
An example:
Lawrence is home to the University of Kansas; last year, one of our reporters got his hands on a set of documents listing every crime report on the campus for the period 2005-2007. He got these documents (Word docs with embedded tables of the reports) on Wednesday. On Friday I had a demo of a browsable database of the reports ready to go; our UI guys put some polish on it, and we ran it online alongside a story looking into trends and interesting bits we picked up from the data (if you're interested, I gave a lightning talk at PyCon last year which covered, in whirlwind fashion, how it was put together. So far we don't have data for 2008, but I'd love to go back and add it, and see a followup story).
We do that kind of thing all the time, and it's neither burdensome nor useless (and we have a bookcase full of shiny things given to us by industry award groups -- two examples I can pull off the top of my head were for this feature on the demise and aftereffects of mining in southeastern Kansas, and our retrospective on the KU basketball team's championship season last year).
People really seem to like this stuff and find it useful (and our former lead developer is recognized as having more or less invented what's now called "database-driven journalism"; these days he's turning out even more interesting uses for online data). Unfortunately, the industry as a whole is stubbornly stuck with the mindset that the printed paper is and always should be their "main product", and most folks are burdened with tech solutions that are far too cumbersome to be put to these sorts of uses.
Anyway, my point is that not all of the stuff going on these days is "Web 2.0 widgets"; there are plenty of us who, when given the chance, are trying to help journalists save themselves from extinction by bringing tech into the newsroom in actually useful and interesting ways.
-
Re:Frontend UI questions
It does have something called "generic views" which can provide basic CRUD and various common views (such as date-based views). However, these are more for prototyping, and would generally be replaced in a production app with something more custom.
I have a crap ton of production code built around generic views. They're in Django precisely because things like "show a detail view of one object" or "show all objects from March 2006" shouldn't require you to be constantly writing and re-writing code: the repetitive parts of the logic can and should be encapsulated in a generic handler. In the book I cover some examples of how to take advantage of this by using the various supported parameters or writing short one- or two-line wrappers around generic views, and I've got an older (but still perfectly working: hooray API stability!) blog post covering the same topic.
-
Re:Maybe we will see more Web
Dude, as was mentioned at PyCon 2007, there are more Python frameworks than reserved Python keywords. A framework shortage isn't the problem.
;-) http://www.b-list.org/weblog/2007/feb/23/pycon-2007-web-frameworks-panel/
--
Simon -
Re:Does it still hog memory?
Plus, no memory leak bug or reimplemented widget controls (I have an operating system that provides those natively, thanks).
That'd be nice if not for the fact that isn't true, and very very obviously isn't true on OS X. Run through this checklist:
- Opera's dialogs and window chrome don't respect the system default font settings -- Opera uses a smaller setting that makes it feel extremely out of place.
- Opera's form controls in web pages don't respect the system default settings -- the system says "Lucida Grande" and Opera says "Arial".
- Opera doesn't actually use native form widgets (it doesn't use them on any platform, really -- Opera's built with Qt, so the quality of the interface is directly dependent on the quality of the widgets Qt provides on a given platform), and it's very easy to spot this. For example, here is a screenshot of a small area of the screen in Gmail in Safari, showing the native fonts and a few native widgets (a couple buttons, part of a text field, and a select menu). And here is a similar shot in Opera.
- Opera uses a strange and fairly ugly tab control based on older versions of the Aqua interface. Tabs are an area where it's OK to improvise -- neither Safari nor Firefox use the default tabs of OS X -- but if you're going to improvise you should do it well (compare: OS X default, Safari, Opera.
- Opera often has problems aligning text on form controls; text on buttons, for example, is often noticeably right of center, and Opera sometimes doesn't draw a button with enough height to comfortably encompass the text, resulting in buttons that look squashed and cramped.
- Opera's search box is not an OS X search box, and doesn't look or function anything like an OS X search box except for being rounded.
I could go on for quite a while here, but by now the point should be pretty clear.
-
Re:Does it still hog memory?
Plus, no memory leak bug or reimplemented widget controls (I have an operating system that provides those natively, thanks).
That'd be nice if not for the fact that isn't true, and very very obviously isn't true on OS X. Run through this checklist:
- Opera's dialogs and window chrome don't respect the system default font settings -- Opera uses a smaller setting that makes it feel extremely out of place.
- Opera's form controls in web pages don't respect the system default settings -- the system says "Lucida Grande" and Opera says "Arial".
- Opera doesn't actually use native form widgets (it doesn't use them on any platform, really -- Opera's built with Qt, so the quality of the interface is directly dependent on the quality of the widgets Qt provides on a given platform), and it's very easy to spot this. For example, here is a screenshot of a small area of the screen in Gmail in Safari, showing the native fonts and a few native widgets (a couple buttons, part of a text field, and a select menu). And here is a similar shot in Opera.
- Opera uses a strange and fairly ugly tab control based on older versions of the Aqua interface. Tabs are an area where it's OK to improvise -- neither Safari nor Firefox use the default tabs of OS X -- but if you're going to improvise you should do it well (compare: OS X default, Safari, Opera.
- Opera often has problems aligning text on form controls; text on buttons, for example, is often noticeably right of center, and Opera sometimes doesn't draw a button with enough height to comfortably encompass the text, resulting in buttons that look squashed and cramped.
- Opera's search box is not an OS X search box, and doesn't look or function anything like an OS X search box except for being rounded.
I could go on for quite a while here, but by now the point should be pretty clear.
-
Re:Does it still hog memory?
Plus, no memory leak bug or reimplemented widget controls (I have an operating system that provides those natively, thanks).
That'd be nice if not for the fact that isn't true, and very very obviously isn't true on OS X. Run through this checklist:
- Opera's dialogs and window chrome don't respect the system default font settings -- Opera uses a smaller setting that makes it feel extremely out of place.
- Opera's form controls in web pages don't respect the system default settings -- the system says "Lucida Grande" and Opera says "Arial".
- Opera doesn't actually use native form widgets (it doesn't use them on any platform, really -- Opera's built with Qt, so the quality of the interface is directly dependent on the quality of the widgets Qt provides on a given platform), and it's very easy to spot this. For example, here is a screenshot of a small area of the screen in Gmail in Safari, showing the native fonts and a few native widgets (a couple buttons, part of a text field, and a select menu). And here is a similar shot in Opera.
- Opera uses a strange and fairly ugly tab control based on older versions of the Aqua interface. Tabs are an area where it's OK to improvise -- neither Safari nor Firefox use the default tabs of OS X -- but if you're going to improvise you should do it well (compare: OS X default, Safari, Opera.
- Opera often has problems aligning text on form controls; text on buttons, for example, is often noticeably right of center, and Opera sometimes doesn't draw a button with enough height to comfortably encompass the text, resulting in buttons that look squashed and cramped.
- Opera's search box is not an OS X search box, and doesn't look or function anything like an OS X search box except for being rounded.
I could go on for quite a while here, but by now the point should be pretty clear.
-
Re:Does it still hog memory?
Plus, no memory leak bug or reimplemented widget controls (I have an operating system that provides those natively, thanks).
That'd be nice if not for the fact that isn't true, and very very obviously isn't true on OS X. Run through this checklist:
- Opera's dialogs and window chrome don't respect the system default font settings -- Opera uses a smaller setting that makes it feel extremely out of place.
- Opera's form controls in web pages don't respect the system default settings -- the system says "Lucida Grande" and Opera says "Arial".
- Opera doesn't actually use native form widgets (it doesn't use them on any platform, really -- Opera's built with Qt, so the quality of the interface is directly dependent on the quality of the widgets Qt provides on a given platform), and it's very easy to spot this. For example, here is a screenshot of a small area of the screen in Gmail in Safari, showing the native fonts and a few native widgets (a couple buttons, part of a text field, and a select menu). And here is a similar shot in Opera.
- Opera uses a strange and fairly ugly tab control based on older versions of the Aqua interface. Tabs are an area where it's OK to improvise -- neither Safari nor Firefox use the default tabs of OS X -- but if you're going to improvise you should do it well (compare: OS X default, Safari, Opera.
- Opera often has problems aligning text on form controls; text on buttons, for example, is often noticeably right of center, and Opera sometimes doesn't draw a button with enough height to comfortably encompass the text, resulting in buttons that look squashed and cramped.
- Opera's search box is not an OS X search box, and doesn't look or function anything like an OS X search box except for being rounded.
I could go on for quite a while here, but by now the point should be pretty clear.
-
Re:Does it still hog memory?
Plus, no memory leak bug or reimplemented widget controls (I have an operating system that provides those natively, thanks).
That'd be nice if not for the fact that isn't true, and very very obviously isn't true on OS X. Run through this checklist:
- Opera's dialogs and window chrome don't respect the system default font settings -- Opera uses a smaller setting that makes it feel extremely out of place.
- Opera's form controls in web pages don't respect the system default settings -- the system says "Lucida Grande" and Opera says "Arial".
- Opera doesn't actually use native form widgets (it doesn't use them on any platform, really -- Opera's built with Qt, so the quality of the interface is directly dependent on the quality of the widgets Qt provides on a given platform), and it's very easy to spot this. For example, here is a screenshot of a small area of the screen in Gmail in Safari, showing the native fonts and a few native widgets (a couple buttons, part of a text field, and a select menu). And here is a similar shot in Opera.
- Opera uses a strange and fairly ugly tab control based on older versions of the Aqua interface. Tabs are an area where it's OK to improvise -- neither Safari nor Firefox use the default tabs of OS X -- but if you're going to improvise you should do it well (compare: OS X default, Safari, Opera.
- Opera often has problems aligning text on form controls; text on buttons, for example, is often noticeably right of center, and Opera sometimes doesn't draw a button with enough height to comfortably encompass the text, resulting in buttons that look squashed and cramped.
- Opera's search box is not an OS X search box, and doesn't look or function anything like an OS X search box except for being rounded.
I could go on for quite a while here, but by now the point should be pretty clear.