Yeah, Bing. The Google-killer. The Decision Engine. $100 million marketing budget.
I finally got my score back from round one of the Cyberspace Open and I think it’s unlikely that I will be (officially) advancing to the next round.
For reference, you can read my entry here. This is the review in full, with the reviewer’s ID and my email addy redacted:
Total Score–Calculated: [21+20+21+21]
Reviewer ID number:
Writer’s Name: Jerry Seeger
Writer’s Email Address:
Structure Score: 21
Dialogue Score: 20
Style Score: 21
Originality Score: 21
Judge’s Comments: The scene has a nice energy to it throughout, though the action feels a little hackneyed and familiar. The relationship between Tommy and Lenore is interesting but it never really becomes something easy to invest in. The dialogue is a little talky and the writing a bit wordy. Try not to open a scene with a large chunk of description – ugh! Apply the 4 line rule throughout (no more than 4 lines of description at any one time). A slimmed down writing style that shows rather than tells – using as few words as possible – would help to bring out the inherent drama and suspense. Less is often more! Good luck.
I knew some of this criticism was coming; the ‘hackneyed and familiar’ part was the subject of a previous lament in a comment somewhere. I failed to break the two out of the ‘modern Bonnie and Cyde’ mold and give the two their own identities. A pity. The opening wordiness demerit is a bit frustratiing; I had put in extra stuff to set the context of the scene better (in an actual script you’d know about the GTO already, for instance), and normally character descriptions would not happen there. They would have been taken care of long before.
As for the wordy dialog, there’s one phrase, “You got some drivin’ to do,” that I really dislike now, but I think the two are talky people. Once again without context the mercurial conversations don’t make as much sense. It goes back to me doing a better job establishing who these people are in the first few words. I failed at that.
Still, I think it’s a fair score and the comments are things I can definitely learn from as I work on other things.
Will I go on to round two? I have to admit that I’m pretty pessimistic on that front. I expect I’m firmly in the middle of the pack of competent entrants, but I think it’s going to take a little more than that to move on. Only time will tell, however, so keep your digits crossed!
As the end of judging nears, I still haven’t received my score. Is that a good sign? Does it mean they are holding back the top candidates so they can sort out the best 100 after their first pass? Do they want to announce the winning scores all at once? Or is it that since I submitted a long time before the deadline I’m at the bottom of the virtual pile, unread?
No way to tell.
However, while I can think of positive reasons my score announcement might be delayed, I can’t think of any negative ones — unless they lost my entry, but I think we’d be able to work that out. They’ve been quite reasonable with other folks who have fallen to technical glitches. So: only good reasons for them to delay telling me my score. Most likely they just haven’t got to me yet. No reason to fidget.
Except that I’m a writer, and I’m bound by the Writers’ Code to be neurotic about stuff like this.
If you poke around this site you will see boxes with rounded corners. If you use Safari or Firefox, you will see even more.
Rounded corners are implemented here in two different ways. The main boxes with the drop shadows are done the old-fashioned way, the way that works on most browsers. Each corner is a graphic with an alpha-channel shadow, and the edges are yet more graphics, repeated as needed to span the distance between the corners. The boxes expand and contract infinitely in both directions. It’s not bad. It’s also a pain in the butt.
Yet, I like rounded corners. They seem friendlier. I have broken down, therefore, and in a few places I have added browser-specific style information to create a softer-feeling blog. Since the rounded corners are purely cosmetic — everything still works just fine in browsers that don’t support
border-radius — I’m not too worried about it.
However, while I was looking into the border-radius CSS property, I discovered several sources that didn’t get it right.
Here’s the deal. The CSS3 standards draft includes a property called
border-radius. Exactly how that property is going to work has not been finalized, but it’s not likely to undergo any more major revision. Meanwhile, Firefox and Safari have already worked out their own
border-radius implementations, called
-webkit-border-radius respectively. Other browsers see the -moz and the -webkit prefixes and ignore the property.
Unfortunately, neither implementation matches how the proposed
border-radius property will act. Oh, dear. When the browsers are updated to match the standard, those
-vendor-border-radius properties may break. A lot of Web designers out there don’t seem to realize that.
NOTE: probably at this point you should open up this handy table to follow along.
It’s not all doom and gloom, however. As long as people using the vendor-specific border-radius properties keep things really simple, there won’t be a problem. Here’s the skinny:
will put a nice rounded corners on any block element of class roundedBox. Safari 4 and Firefox 3.5 (the browsers I have to test on) will work today, and when the formal
border-radius is adopted and the other browsers support it, everyone will be happy. (Remember, of course, that in the meantime a large part of your audience will still see squared-off corners.)
The tricky part comes when one wants to specify elliptical corners, or specify different radii of curvature on different corners. When you start getting fancy, things get a little messed up. Let’s tackle the second one first, because it’s possible to find a way to specify the different corners that makes everyone happy. It’s just long-winded.
border-radius is really shorthand for four properties:
border-top-right-radius, and so forth. Therefore it’s perfectly safe to specify each corner independently, and all the browsers will act the same way:
Note that the names of the four corner properties are different for Mozilla. Aargh. All the more reason to hope the spec is finalized soon. I put the four properties in the order the software considers them when parsing the shorthand notation, just to get into the habit.
All those lines of CSS can be a pain in the butt, but it’s bulletproof and will work on into the future. But wouldn’t it be nice if you could use shorthand for the border radius the same way you do for margins and padding? The boys at Mozilla thought so, and the CSS3 standards team thought so, too. Webkit (Safari) seems content to only support the long-winded method for now (at least support it properly – more on that later).
Before talking about the differences between the browsers and the CSS3 spec, let’s take a quick look at the theory. As with properties like
border-radius property is just a shorthand so you don’t have to specify each corner individually. If you use one number, like
border-radius: 10px; the style will be applied to all the corners. If you supply four values, the four corners each get their radius set, starting with the upper left and working clockwise. So far, so good, but there’s trouble ahead.
[The following has been edited since it was first published. I first said that Mozilla was doing the following drawing wrong, but it looks like they have it right and Safari is wrong. Sorry for any confusion. To make up for it I added
box-shadow here and there for browsers that support it. They’re sweet!]
The difference is elliptical corners. CSS3 calls for them, but the draft isn’t very well-written. The mystery lies in what should happen when two values are specified:
border-radius: 20px 10px. When you are specifying a single corner, the result will be an elliptical curve. When using the shorthand, however, Safari draws all four corners with the same ellipse, but Firefox (and the CSS3 spec) draw round corners that turn out just like the example above.
According to the spec (by my reading), when using shorthand if you don’t use slashes you don’t get ellipses.
NOTE: The most recent builds from webkit.org match the spec. I don’t know when those changes will reach Safari, but sites using the two-value shorthand may have to deal with some inconsistencies between browser versions. Not sure, but I would avoid using that syntax just in case.
What about if four values are specified?
Once again Webkit-based browsers like Safari and Chrome fall short. The Webkit team seems content to get the longhand method of specifying corners right, but not the shorthand. Mozilla, in the meantime, has worked out the most complex and versatile form of the shorthand, but disagrees with the spec fundamentals.
To use shorthand to specify four different elliptical corners, you would use something like:
-moz-border-radius: 20px 10px 20px 5px / 5px 10px;
where you specify up to four horizontal radii and then up to four vertical radii. The numbers before the slash are the horizontal radii, starting from the top left. If only two numbers are given, they alternate. Three numbers means top-right and bottom-left share. The y-radius values are the numbers after the slash, and are distributed the same way. Clear? Good.
I have read that if the text rendering is vertical, the horizontal and vertical parts are reversed, but I see nothing about that in the proposed specification.
This will make a lot more sense if you study the twoblue-shaded lines of the table.
While we’re looking at the table, note that Safari is perfectly capable of displaying the most complex borders, but they have not implemented the shorthand notation (except for the bit they did wrong). They’ve done the hard part, but left out the one-day coding job of parsing the shorthand strings into the properties for each corner. Odd. The rules are really very simple for a machine.
So what does this all mean?
In conclusion, while it’s possible to write different sets of
-vendor-border-radius CSS properties and get what you want, things start to get quite messy. It’s a lot of effort for aesthetic touches that half your audience won’t see for the next couple of years. I’d advise just staying away from elliptical corners for now, and specifying round corners individually if any are different. It’s a bit more typing, but it’s a lot safer. Stay away from
-webkit-border-radius: with two values.
I wrote this scene over the course of two days, and I stopped myself before I edited all the fun out of it. (At least, I hope I did.) Lenore and Tommy seem to be in a heap of trouble, but can they even trust each other? The scene that comes after this one is awesome, if unwritten.
As a reminder, here’s the premise:
Your PROTAGONIST is in a jam. He (or she) had been relying on deception in order to further his objective, but his ENEMY has figured out the ruse. Write the scene in which your protagonist’s LOVE INTEREST confronts him with this information acquired from the enemy – while in staging it in a tricky or dangerous situation.
I learned a few things while writing this… but let’s cut to the chase.
There are still several hours left before the deadline, but, well, I was done, so I submitted my entry. I just saw this message:
Seeing this screen means your entry arrived.
Finally, congratulate yourself for having the courage to say,
“I can create on deadline,” and then doing it. Yay!
There is nothing more to do; my fate is in the hands of the judges now. Let’s all keep our fingers crossed for a top-100 finish. Think positive thoughts and all that crap. I’ll be posting my entry here in a while, but I’m going to reread the rules to make sure it’s OK first.
To the rest of you still working on the challenge: You can do it! Go Team Muddle!