Coming Soon...
I mentioned a couple times that I've been working on redesigning my blog. I'm not unhappy with what I have now per sé, but I do feel like I've let it stagnate. Also, the code is no longer something I'm particularly proud of; I've learned a lot of PHP (and about web development in general!) since 2003 when this was written. I've been really wanting the opportunity to grow this space into a bit more mature of an application.
Well, as of last week, I've started work on this in earnest, and hope to have it completed within the next couple weeks. While the database structure won't change (much), I'm rewriting the code from the ground up, and it's going to be very different in a variety of ways, many of which I haven't made a final decision on yet.
On the understanding that what is there now isn't complete, I invite those who are interested to preview what I'm writing over at beta.lukesneeringer.com. You won't be able to interact with it at all yet (I haven't written any of the forms), and certain things as fundamental as the color scheme are likely to change, but you can see a bit of what is cooking in my head.
One note, geared primarily for all those in the audience who are named Elli Swift: I am aware that the archives and options links don't work, and that the search box doesn't actually do anything at the moment. ;-) (That said, anything else is fair game...)
Posted by Luke at 9:33 p.m.
Will you be bringing over all your archived blog entries from years past? I hope you will...
Posted by loyalfriend on 2007.01.10 at 4:47 p.m.
I'm not significantly altering the database (which is where those live).
Posted by Luke on 2007.01.11 at 1:21 a.m.
It's nice clean and spare. I highly recommend making some use of -moz-border-radius and giving those of us using firefox I nicer site. And I'm not just saying that because I use it far too often on my site. :p
Posted by Tim on 2007.01.11 at 3:20 a.m.
That sort of thing would be really cool, except that it would keep the site from validating as CSS.
I am considering getting drop shadows going, though.
Posted by Luke on 2007.01.11 at 11:11 a.m.
FYI, I'm viewing your blog in Firefox on Ubuntu and I'm getting the following error message at the very top of your blog:
Notice: Undefined variable: date in /var/www/luke/html/index.php on line 10
Posted by Chris on 2007.01.11 at 2:57 p.m.
And I'm getting the message:
Notice: Undefined index: do in /var/www/luke/html/entry.php on line 4
and the same message also on lines: 719, 781, 47, 106, 347, 393, 405, 484
And...
Undefined variable: starttime in /var/www/luke/html/global.php on line 259
Posted by Chris on 2007.01.11 at 3:01 p.m.
Yeah I see the same thing on my laptop.
Posted by Wanda on 2007.01.11 at 3:13 p.m.
Whups
Posted by Luke on 2007.01.11 at 4:10 p.m.
Nnn.... Gandalf!
I seriously didn't understand a word of what my brother said. :)
Posted by Nathan on 2007.01.11 at 7:45 p.m.
Firefox = a web browser
Ubuntu = a distribution of Linux, an operating system
Undefined index & undefined variable = Errors
Posted by Luke on 2007.01.12 at 1:24 a.m.
Heehee, I just had an evil thought. Chris, you should teach Nathan how to use vim...even better, over the phone! :evil:
Posted by Luke on 2007.01.12 at 1:27 a.m.
Man... that would rival telling someone how to build a to-scale replica of the eiffel tower out of legos. Both people blindfolded... and dead.
Posted by mcoker on 2007.01.12 at 2:29 a.m.
The guy that sits in the cubicle next to me spent an hour with in friend walking through editting a file in vim the other day. Apparently he's setting up a box to run RedHat Fedora 6 and he needed to edit a file (Luke knows which) and so he walked him through it over the phone. I was very impressed.
Posted by Chris on 2007.01.12 at 4:00 p.m.
Here's my 2¢: I like what I see so far, except for the link-type icons. I don't like having inline icons to tell me what a text nihyperlink points to—my browser has a status bar for that, and the icons are distracting when I'm reading. (They do snazz up the byline nicely, however.)
Having the datestamp and timestamp in different locations for entries, but located together for comments, is inconsistent...but okay. I do like that it makes the bylines for each visually (though subtly) distinct.
Have you thought about adding permalinks for entries and/or comments? (On your current layout the only ways to find the direct link to an entry are to click the comments link and then truncate the anchor from the URL, or go through the archives.) You could link the entry titles...or the datestamp in the title bar...or the timestamp in the byline at the bottom. Or all three, but that'd be excessively redundant.
As for comment permalinks, when I reference someone (e.g. on other sites), I like being able to link as closely as possible to the original text. With your current layout this is possible (though tedious) because each comment has an anchor tag...on the new one the anchors are gone. Bringing them back would be nice; adding clickable permalinks would be nicer. :)
So maybe the byline format could be:
Posted by {Name} {email icon & link} {website icon & link} on {datestamp} at {timestamp & permalink}
I'm all in favor of drop shadows and other nifty visual effects, so long as they don't decrease text legibility (e.g. a too-opaque background image behind text).
Lastly, I'd add some whitespace and/or some kind of footer at the bottom of the page (akin to your current layout) as a visual cue that the end has been reached. When I see the entry background color extend all the way to the bottom edge of the window, I tend to expect more if I just keep scrolling down.
All right, maybe that was more like 5¢. Keep the change! ;)
Posted by Alan on 2007.01.12 at 6:02 p.m.
By the way, I love the photo on the Wikipedia page for "error." And next time I need help with vim, I'm skipping the man page and calling Chris!
Posted by Alan on 2007.01.12 at 6:04 p.m.
Hmm...character entity codes (¢) aren't decoding properly in the new layout.
Posted by Alan on 2007.01.12 at 6:06 p.m.
/etc/X11/xorg.conf
Posted by Luke on 2007.01.13 at 2:25 a.m.
Thanks for adding the permalinks. Entity code handling is only partially fixed, though: In my third comment, the ¢ is now showing up, but the closing semicolon is also being joined to the subsequent closing parenthesis to make a winking smiley. And I just noticed this is also true on the current layout. Looks like your script (or is it the database?) is outputting the character itself, rather than the code, in the generated XHTML...which is fine so long as page encoding is defined correctly, but I wonder whether leaving the entity code intact would prevent the semicolon being double-parsed?
Posted by Alan on 2007.01.13 at 7:03 a.m.
Actually, the code is being left intact, which causes the ;) to be picked up by the string replace function looking for it to generate the smiley.
There really isn't any good way around that. Expecting \s (whitespace) or \b (string boundary) on both sides of the smiley won't work as a solution because people commonly will put the smiley adjacent to text and expect that behavior to work. So, basically, you can't use an HTML entity next to a closing parenthesis. Oh well.
Posted by Luke on 2007.01.13 at 7:09 a.m.
The entity codes are left intact? Odd: when I view source it shows the character instead of the code, at least for ¢ and — (but not for &, which until now I had not used in this thread—I'd just typed an ampersand on the keyboard; it shows up in source as the entity name). Maybe they're left intact on input, but parsed on readout from the db, either by mysql or php? That still wouldn't explain why ampersands behave differently, though.
And if the string replace for the smileys is replacing the closing ; with the icon, shouldn't that break the entity encoding? &#mdash doesn't render as a dash, does it?
I'm a bit confused.
Posted by Alan on 2007.01.13 at 7:22 a.m.
When I view the HTML source on Firefox 2/Mac, I see the HTML entity you typed (¢). And I know they aren't being parsed on exit from the database because I haven't written said parsing in the last few days...with the exception of looking for lone &s and changing them to & (because I want XHTML compliance).
&#mdash isn't going to render as a dash because the # is breaking it. You should be writing —, which will render as — in the output and — in the source.
Posted by Luke on 2007.01.13 at 7:29 a.m.
Oohhh...whether the semicolon is necessary or not depends on the browser. The XHTML standard requires it, but a lot of browsers are relatively forgiving on that point (grr).
The semicolon is therefore being parsed into the smiley, and not being parsed by the browser.
Posted by Luke on 2007.01.13 at 7:36 a.m.
*smacks head* D'oh.
Weird: When I "view page source" I see the entity code; when I "view selection source" (highlighting a special character first) I see the character, not the code. Firefox bug? (Ff 2 on WinXP SP2)
Posted by Alan on 2007.01.13 at 7:37 a.m.
Yeah, my money's on a Firefox bug for that one.
Posted by Luke on 2007.01.13 at 7:39 a.m.
So...your smiley parser is actually breaking your XHTML compliance (if not validation)? ;-)
Posted by Alan on 2007.01.13 at 7:42 a.m.
Correct. Nothing I can really do about that.
Posted by Luke on 2007.01.13 at 7:45 a.m.
Hmm. Actually, I found a creative solution around it. Go me. :) (Note that one of my examples above still converges because the ¢--which is what is there--doesn't constitute an XHTML entity bordering a closing parenthesis.)
Posted by Luke on 2007.01.13 at 7:59 a.m.
I thought you might, given enough of a push; hence the teasing tone of my previous comment. Good work! :)
Posted by Alan on 2007.01.13 at 8:01 a.m.
Get a room!! :-P
Posted by mcoker on 2007.01.13 at 10:32 a.m.
Post a Comment