You might think that Apple holds both [the open web and the App Store] in equal esteem, but
its release of Safari 5 shows that Apple has less regard for publishers on the Web than it does for publishers (and developers) it wants to entice to come to the App Store.

And the App Store is becoming its own little mirror-reflection of the Web. You’ve got content from news providers, you’ve got social networking, you’ve got games, RSS readers—the list goes on and on. You’ve also got, courtesy of Apple, a 100 percent Apple-owned, Apple-powered advertising platform called iAds.

…

in the end we’re left with a) an open platform [Safari] where Apple is willing to toy with Web publishers, modify their content presentation, and suppress their ads, and b) Apple’s curated, closed platform, where everything is done by Apple’s rules or it’s not done at all.

Fisher is honing in on Safari’s new Reader feature, a space Arc90 has been treading for some time. So it’s somewhat synchronistic that Arc90 echoes the original frustration with Apple’s anti-open web model (though not it’s Reader) in the blog post, “Why We Built Readability” comments,

…publishing finds itself looking elsewhere to solve the puzzle of distributing and monetizing. Magazines like Time, Wired and Popular Science have decided to invest in delivering purchasable “packages” of their content that work on Apple’s iPad.

…

For us, the Web is the right bet. The notion of tethering content delivery to a particular proprietary platform or hardware device is admitting defeat.

To be clear, I am no longer a full-time freelance web developer. Indeed, I haven’t been a full-time web developer for a number of years, though I do still take projects on the side.

I did, however, think I had enough info to write out the following rather lengthy answer, which I hope to refine and turn into a lesson page later on this semester. There are quite a few better sources to turn to than I, and there have been a few recent articles and books on this subject, but here’s how I framed this particular answer in a way that hopefully walks the student through my thought process and tips them off to at least a few of the bigger picture items that must be considered sooner or later:

First, you need to decide if you’re going to charge hourly or lump sum. I prefer the latter, and I think clients do too.

Even so, I still start by calculating how much I need to be earning per hour–this is a figure I keep internally, and don’t share with clients.

Then, start adding upwards.

For instance, now that you’re working freelance you’re considered to be self-employed by the US Government, and will need to add about 30% for Federal taxes on top of everything else. (Make sure you put that 30% in a separate bank account!) What about State taxes? That varies state-to-state, so check your local codes.

There’s also a matter of other costs you’ll eventually need to roll in to your charges, especially if you look at doing this full time: What about Internet access, computers, software, electricity — these don’t come free! Do you need this work to pay for benefits for you/your family (health insurance, dental, life, etc)? What about advertising (if any) or time spent drumming up business? These need to be absorbed, too.

I’m going to keep it simple in this example and exclude those costs, and I think you probably don’t have to worry too much about this when you’re first starting up–especially if you’re doing freelance in addition to another job. However, be sure to consider these costs later after you move your business forward.

So if that the take-home amount is, say, $15/hour (which is not too bad for someone just starting out–most of my student developers get less than that) first add 30% for taxes, rounding up to $20/hour.

Then, figure that if you were doing this full time you’d be working at least 40 hours a week at least 4 weeks a month. This gives you a number through which you can absorb business costs on a per-hour basis by simple division. So if I’m working from a home office my internet, electricity (for just my office), computer upkeep might add up $160 a month, which is convenient because it means I just add another dollar to my hourly rate. Etc.

The next number to determine is tougher. How many hours will the project take you? Be realistic, and include meeting times. The best way to know for sure is to have tracked your time on projects in the past. I’ll give you just one example: I wrote XHTML and CSS for someone’s resume the other weekend, which turned out to be a 3 hour job including the initial meeting, and some minor experimentation with CSS 3’s @font-face property at the client’s request. Then I spent an hour testing it across browsers and making minor adjustments. So 4 hours for 1 page of content.

In this case we just needed one page, but in sites with multiple pages using templates will make things go faster. Because of this I usually charge on a first-page, additional-page basis, if that makes sense.

At any rate, it’s common to undercharge early on by not accurately estimating the time involved. And that’s OK early on, because you’re learning! But learn from your mistakes, and track your hours, so that in the future you can be more on-target and provide good service at competitive rates. Consider using a project management or time-tracking tool to help you with this.

Another practice I’ve heard others use in the past is to take my estimated time for a project and double it. This is based on the presumption that we always underestimate how much time tasks take us. I think this is true initially.

So now I know my per hour rate ($21), and I’m confident that for a media-free (text-based) static page it takes me about 4 hours. So I might charge $80 for that first page, and, using that first page as a template, charge $20 for each additional page. Now we’re starting to have a basic formula!

Oh, but what if you have to do visual design? Logo design? Will it take you 20 hours to come up with a good visual design? 40? 60? What about changes the client will inevitably request? Certainly you want to include the client at each step, from thumbnails to comps to finished versions. Heavy involvement early on will reduce the likelihood of conflict and frustration later.

Now if Javascript or PHP come into it, we start talking big money. Not just because it takes longer to develop, but because you must work with other people’s web servers, you must be secure, your code must not break on any browser, you must case-test for a number of different user scenarios, etc.

Don’t be afraid to ask yourself if you need to outsource tasks where your skills are not yet adequate. This is a good way to ensure your client gets what they are paying for–and can save you time in the long run. For instance, if I had a client needing a Flex app, I’m not going to spend 200 hours on it when a skilled Flex developer could do it in half that time. Sure, I have to pay them, but sometimes you can barter your skills for theirs.

Finally, make and maintain a master list of services you could provide with a dollar charge next to each, i.e. Basic web page production (HTML & CSS): $200 first page, $50 each addtl page. MySQL database set up: $50 per table, limit 30 fields. etc. I keep my own Excel spreadsheet with as many options as I can think of, and I modify this as I learn more about my own time, resource expenditures, and costs.

That’s it. As I said, this was just an e-mail I kicked out to a student, and this omits important info on contracts and agreements, but it’s a big topic, one which I expect to reflect upon and revisit in this or another post.

To remedy this I have, for quite some time, maintained a custom bit of very basic Javascript and CSS that sets the default view of news items to hidden, with a clickable link to show the entire list from the My Moodle page:

Nothing fancy, and even as I look at it now I can think of improvements…

We just upgraded to 1.9.8 this semester, and because this snippet modifies Moodle core I had my developer Kevin re-test the snippet before I asked our server admin Paul to replace the existing function as follows:

file Location:            '/course/lib.php'
file line:                    "800"
function to replace: "function print_overview($courses)"

Here’s the actual replacement function:

The UVU Blackboard server now allows designers to require Respondus Lockdown Browser (LDB) on assessments. This means that if an assessment is set to use LDB, the end-user (test-taker) computer must have the free LDB software installed (Bb should prompt the user to install it before the assessment can be accessed). UVU’s Testing Center has installed LDB on all its computers and is testing it before next semester. We presume this is pointless unless the Bb assessment has LDB selected, but are looking into it. In any case where LDB is used to take an assessment, “lock down” happens according to Respondus’s descriptions–even if the exam itself is not triggered to require Lockdown. I asked Respondus to clarify the “switch” in Bb, and they responded this afternoon:

The “switch” in Blackboard and other course management systems helps insure (sic) that the assessment can only be taken with the Respondus LockDown Browser. Without enabling the switch, students can take the assessment using any browser they want, including the secure browser.

For Distance Ed this means that if an instructor wishes to use LDB, we must ensure proctor locations have the LDB software installed. This may require adding wording to the proctoring info web page. For the UVU Testing Center, if they make LDB the only web browser installed on lab computers, all assessments have no option but to be “locked down”.

Brian Swaney has written a lengthy post on LDB, explaining why he thinks it’s an awful idea that only inhibits cheating in limited scenarios, and though Brian’s post gets a little bit out of hand, I do agree with most of his points. Here’s a summary of these, some of which John Krutsch, Marc Hugentobler, and I have brought up in our conference sessions, “How to Cheat Online” and “The Cheatability Factor“:

1. LDB may encourage institutions to take advantage of broadly accessible but ill-suited environments for testing, like open student computer labs.
2. Unless the physical environment is also “locked down” the LDB will do little to inhibit cheating (crib notes, use of a 2nd computer, mobile devices).
3. Unless student identities are verified, LDB does not prevent impersonation (note: LDB doesn’t claim to).
4. There is a line between securing assessments and respecting student privacy. I don’t think LDB crosses it by any means, but Brian raises some legitimate concerns about requiring software installation.
5. All technology, including LDB, can be hacked.
6. The kinds of assessment best protected by LDB may not be good at assessing important kinds of learning. But LDB may be alluring as a (false) panacea for measuring all kinds of learning.

Now like the iPhone/Touch the iPad can use thousands of “apps”– miniature applications developed solely for use on iPhone/iTouch/iPad, and sold through the Apple store. What’s always been disconcerting about the app development process is that Apple controls not only the specifications for apps, but also restricts what apps are made available for use on their product, censors content, and even denies what technologies can be used to produce such apps.

Apple has the right to do all this, of course–it’s their device. Even though the approach out-M$s Microsoft, Apple’s restrictions on production and content of the apps is only one side of a larger problem. What really concerns me is how Apple’s app model will impact digital content on the open web, and I’m not talking about Flash.

The Web as an App

We’ve seen already a number of apps that replicate core functionality of web sites. We’re starting to see more apps produced by content providers as a supplement to their existing web-based content (e.g. Wired, NPR, WSJ). But how long until this supplement supplants the web-based stream? How long until consumers are hooked into fee-based access to this content under the illusion that it’s only available through the app?
I believe Apple has been rather insidious, if clever, in their iPhone/iPad app model, wherein the closed nature of their system requires a kind of fake innovation in the development of “new” apps that do little more than their web-based cousins; certainly little more than what’s already possible with a web browser and a little creative use of standards-based web languages. Instead, these appear to be little more than an opportunity for approved providers to elicit fees in new ways from end-users.

Don’t get me wrong: I’m all for businesses finding new ways to make money by improving service or a product, but is that what we are getting here? The drive to develop web-based products as apps seems entirely backwards, for we already have the one tool we need to facilitate mobility of both content and services: the standards-compliant web browser. What technologies do we need? Not C, C++, or even Flash, but how about HTML, CSS, Javascript, XML, and PHP? How about the open web standards that have facilitated the information access revolution we are experiencing?

Now a “special” path to mobile device development is nothing new; even the W3 tried to sell us on HDML rather than alternative CSS and minimalistic but semantically correct XHTML. But I think time has proven that this is wasted effort in the face of a broadly-accepted, dually-purposed web site constructed on sound principles of web design and utilizing creative applications of open technologies. Even NPR seems to prove this point by the fact that it has not only released it’s own iPad app, it’s also reworked it’s web site to be “iPad-friendly” for those who don’t want to download the (free) app. And at first glance it looks like the web site provides the same essential features.

Enter Blackboard

As expected, in an attempt to capitalize on the iPad buzz and finally make good on years of broken promises for mobile accessibility, Blackboard has unveiled its iPad app, which

recreates the course experience of Blackboard Learn™ … and lets students check grades and assignments, add discussion board comments and blog posts, email instructors and classmates

How stunningly innovative! I surely couldn’t do any of that on a mobile web browser?

I probably rehash this example too often, but I remember sitting in a session at a WebCT conference 5 years ago that was supposed to reveal WebCT’s innovations in mobile delivery of content. Turned out the WebCT rep had nothing to share, but hoped to take ideas from the audience. Disappointed, I turned to my Palm Treo phone and did some grading through Blazer on Moodle. Though the HTML, CSS, and Javascript of Moodle was still disappointingly primitive at the time, it was just good enough that the weak Blazer browser could handle it, and demonstrated the power of using open web standards.

Michael Feldstein suggests that this sort of “innovation” will promote the iPad itself, saying, “if I were a student or faculty member heavily using Blackboard and thinking about buying an iPad, I might find this app to be an additional motivator to buy one”. I bet Bb is hoping the reverse of this will be true: that by providing all their students with an iPad colleges like Seton Hill and George Fox will create a scenario that fits just right with their particular e-learning solution, which is “the industry leader” with full support for “mobile devices”.

This restrictive piping of information that we currently take for granted on the open web is of greatest concern to educators, perhaps, because it has the potential to retard the development of new models of learning. I don’t mean “learning by doing”, though iPad’s failure to support creative production is notable (Jeff Jarvis writes, “It turns us back into an audience again”); I mean particularly developing models that encourage increased learner self-regulation and networked direction along variable learning paths. Such models require access–both broad and deep–to information and depend upon content aggregation, parsing, and re-dissemination. These capabilities have only recently begun to be realized through the open web, thanks in large part to web standards. What schism might the apps model cause in this new standard of information accessibility? What locks and limitations may now encrust upon the ideals of the open web?

.post img { max-width: 100%; }

This prevents the sort of thing we often see when an image is slapped into a blog post without being resized especially for that design. Here’s an example this just popped up in my Google Reader:

In addition to preventing IMGs from breaking out of the box (or, worse, growing the box) this can be applied to other elements as well. In the case of my themes’ CSS I also include OBJECT (and, just to be safe, EMBED):

.post img, .post object, .post embed { max-width: 100%; }

With the entrance of HTML 5 one can imagine adding/replacing AUDIO and VIDEO in this list of selectors.

I’m thinking about this today because on Twitter Jeffrey Zeldman RT’ed Stephanie Hobson quoting Ethan Marcotte:

This is a fine solution, and reminded me that just last week I was talking with colleague Ken Woodward applying max-width in a more generic fashion–more generic, even, than to all IMGs:

div * { max-width: 100%; }

This is very broad, of course, and could cause problems in a number of particular designs, however I’m thinking the principle is still valid, particularly as it applies to inline elements, for the W3 reminds us:

If an inline box cannot be split (e.g., if the inline box contains a single character, or language specific word breaking rules disallow a break within the inline box, or if the inline box is affected by a white-space value of nowrap or pre), then the inline box overflows the line box.

Why wouldn’t I just write the rule without the DIV ancestor? Most elements that I need to control naturally fall within a DIV, and this limitation helps me feel safer, though I haven’t done enough testing to see how when/where it might fail. I am certain there is probably not enough specificity to override width problems that may be caused by miscalculated pixel widths of directly targeted descendant elements (i.e. DIVs), but those should probably have been done in percentages anyway. If specificity is a problem, adding a relevant parent CLASS or ID to the selector could probably solve it.

I’ve finally gotten around to reading through Ong’s “Orality and Literacy” (I skimmed it as an undergrad), a book which compares primary oral cultures to literate cultures, weighing the influence of technology. Mott’s point, that we need not teach students to learn information, but rather information-finding skills, reminded me of a passage that I highlighted in the early section, “Some Psychodynamics of Orality: the development of text, though “conservative in its own ways” ultimately “frees the mind of conservative tasks, of its memory work, and thus enables the mind to turn itself to new speculation”.

I expect this idea may be elaborated on later in the book, but as I read this I automatically wondered if instant access to networked information obviates “memory work” (i.e. memorization of information) even further, and thereby further freeing the mind for “new speculation”. If so, we can understand this as ultimately an advantage, a progression leading to future intellectual and cultural developments.

The next question: are we yet ready to recognize these “new speculations” for what they are? For what they and might be?

Ong reminds that literate individuals and cultures do lose intellectual and cultural abilities that are apparent in primary oral, and so we might expect similar losses as we become an instant-networks culture. What might these losses be? I know a number of critics have pointed to attention span, “flow”, sustained and deep reading, traditional concepts of plagiarism, etc.

More than just troublesome for pretty CSS-based pages, quirks mode, triggered on standards-compliant pages, can negatively affect the usability and functionality of the learning experience. For example, we use an inline quizzing Javascript that renders questions and answer choices and feedback based on standards mode CSS. In quirks mode this self-assessment tool is useless.

Blackboard Was Made For Quirks

Basically quirks mode means the browser thinks your web skills are not up to snuff, and the browser therefore renders your CSS in a non-standard fashion. Quirks mode is triggered when a DOCTYPE, e.g.:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

…is missing, or invalid, or unknown, or not where it should be (i.e. the first line of the document).

javascript:alert(document.compatMode) pasted into the Internet Explorer address bar kindly informs us that this browser is rendering this page in quirks mode. Firefox will tell you if you go to Tools > Page Info. Advanced Box Model Test

But even if you’ve been careful to put a valid DOCTYPE into your web pages, once it’s loaded up into Bb Vista and linked to, either from a Folder or a Learning Module, the browser will go into quirks mode. Why does this happen? Simple: Bb Vista inserts XHTML and JavaScript at the beginning of all web pages onload. 140+ lines of it, to be exact. It’s an odious thing to do, but, what do you expect? It’s Blackboard.

It may (or may not) be important to note that this does not happen when viewing a page in the File Manager–only when a page is loaded from a link within the course.

What You Can Do

Not much. And yet this could be a big issue for Internet Explorer users (FireFox renders page in quirks mode [not "Almost Standards Mode" as I'd hoped], yet most standards-compliant XHTML and CSS still render well).

And though most users are still on IE 6 or 7 I had some hope for a way out with Internet Explorer 8. You see, Microsoft promised that “a page explicitly opts into standards mode” when it includes “a metatag in the page that specifies IE=8 or IE=EmulateIE8″. For example:

<meta http-equiv="X-UA-Compatible" content="IE=IE8" />

In practice, however, this META tag alone does not force IE8 into standards mode in Bb Vista–the misplaced XHTML is apparently too much for IE8 to ignore.

So the most practical solutions I can think of are:

1. Write custom CSS for Blackboard that renders (or re-renders) the page according to the quirks mode box model. This could be done using Internet Explorer conditional comments, for example:

   
   <!--[if IE ]>
     <link href="ie-quirks.css" rel="stylesheet" type="text/css" />
   <![endif]-->
   
   

   I haven’t yet considered what CSS rules would need to be written to accommodate this, but if it was possible this seem like the most robust and efficient solution.

2. Rewrite the page with Javascript. After Bb has loaded (or begun to load) the page, Javascript triggers a full rewrite of the page, either wiping out or rewriting the Bb XHTML and Javascript in a more appropriate location (e.g. in a targeted, ID’ed element). I’ve asked one of my developers to try this out today, but already fear the additional load time it might put on the Bb-hosted page.

Any other ideas?

If this were only about appearance I wouldn’t be raising a fuss, but this can and does affect the usability of certain e-learning tools, and forces developers to ask, “How will this work in Blackboard?” yet again.

Tim’s applied this to “shelf shadows”, where a nav item appears to be propped up on a shelf with a shadow below:

I looked at the CSS and thought, “This is cute, but could be more elegant with just two 1kb images.” So I wrote it, and it turned out fine. In fact, it turned out better, in my opinion, because the shadow edges were anti-aliased. I showed my developer Tyrel Kelsey the results, then bragged, “I can even make both the shadows and the shelf size scale with the text.” Then whipped up that solution as well.

In short, my first solution used two images: a x-repeating 1×20 “shelf” hooked to the UL, and a 10×20 “shadow” hooked to each LI in place of Tim’s border corner.

My second solution used a 1px square for the top “shelf”, and a 1px border–both hooked to the UL. The top shelf was set 1em from the top to allow for scaling.

The “shadow” was a much larger image, 100×200, and set .1em to the left and 1em from the top of each LI, thus masking it’s gargantuaness (similar to sliding doors).

It was a slick application for the same effect, but then Tyrel popped my balooon.

“Are you on FireFox 3?” Tyrel asked. “Because mine already scales on FF3, and it doesn’t look all jagged like yours.”

Page zoom. I still am on FF2, and I remembered earlier in the week how I embarrassed myself in the web design course I teach when the page zoom disturbed an effect I was demonstrating. In fact, a lot of the em-based scaling approaches so popular just a year ago are sliding towards obsolescence thanks to page zoom on IE 7+ and now on FF3 as well..

Not only are they made obsolete, current CSS-based designs that are enhanced by the elasticity (e.g. layouts with reading-width columns or other applications of em-based scaling (e.g. sliding doors) may look worse with page zoom. My second example sure did when scaled in IE7. And if you open my design 2 on FF3 and compare the page zoomed rendering to the rendering with Zoom Text Only turned on, you’ll agree that the clarity is compromised in the former.

So while I’m proud of my two CSS variations on Tim Wright’s shelf-and-shadow concept, and they are great solutions for older browsers (I can’t believe I’m referring to FF2 as “older”!), it’s also clear to me that em-based scaling and elasticity is on it’s way out, and browser-based page zoom will solve a lot of designer’s accessibility-influenced design challenges–but not, perhaps, without affecting our “tricks” of the past.