I just came across an awesome site for streaming TV shows and movies. It’s called Hulu. Apparently it’s a site supported (or built?) by NBC/Fox, so the videos are all of incredible quality. I came across it while looking at a list of high-traffic Rails applications (and it’s one of them).
So if you’re looking for another way to be distracted, check out Hulu. Here’s one to get you started: 2008 Tostitos Fiesta Bowl.
summize.com is a site that scours the internet for discussions and reviews of a product. I don’t know how legit the algorithm is, but it does a couple of cool things.
Firstly, it sorts the results by “helpfulness” instead of “highest/lowest” ratings. Secondly, it has some really nice (visual) rating scales. At a glance you know how many people rated it and the majority vote (everyone knows red is bad and green is good). It also provides percentages for each piece of the rating when you hover over the sections.
In my opinion, it’s a much better interface than the traditional star rating; however, it also allows you to view the ratings as stars, if you’re so inclined.
For online word processing I choose Writeboard because of its simplicity and textile support. But anymore, the options are endless. Buzzword is probably the latest option for online word processing, and it looks really slick. Edit mode is the actual document, so there aren’t any text areas, which is nice. Also, all of the options are integrated very well (especially the inline commenting). It was built using Adobe FLEX.
While textile is a much-needed feature for me, I also have a hard time using something that is ugly. Personally, I see Google docs as ugly. Buzzword, however, is on the other end of the spectrum. If you don’t particularly enjoy the “Flash” feel, you probably won’t like it. But the documents are extremely nice looking. It feels as though they can actually be designed, which I like.
If I were one who needed to collaborate and had a real purpose for online documents (such as for work), I would almost have to use something that produced Buzzword-like documents. If online document writing/collaborating/sharing is a need for you, it’s worth checking out. Seriously.
A natural inquisitive human behavior that lends itself to exploration and investigation.
I’m a very curious person in regard to a lot of things. I enjoy looking at someone else’s work, and sometimes comparing it to my own. I’d say many others are curious in the same way. When I posted about redesigning this site, for a couple of days, the traffic rose from (an average of) 60 visits per day to 110 or more. I’d say curiosity was the reason.
Golf Trac currently has 68 signups. I’m betting at least half of them aren’t by golfers, and I bet over half have no intentions of actually using it. They’re just curious. Plus, anonymity takes curiosity to a whole new level.
Fortunately, this site and Golf Trac serve a purpose above how many visitors/users I can attract. Honestly, I would do nothing different if I had 0 visits and 0 sign-ups. For me, being able to build anything I want is gratifying enough. But I do believe curiosity is one reason why it’s so important to keep software evolving. Change keeps those curious minds coming back. Plus, applications that neglect change often fall out of favor and become obsolete.
Dead software is about as attractive as dead batteries.
Last night before bed, I checked reader to see if there was anything pressing… there wasn’t. However, I noticed a few changes to the reader itself:
I didn’t thoroughly check for more features, those were just the apparent one’s. I figured I’d give it a more in-depth run this morning, but it’s back to normal now. Personally, I think they had to rollback. I say this because my photography feeds reported 1,000+ unread and I know I don’t have over 1,000 unread posts just for photography. Either way, I’m guessing a few minor updates are just around the corner.
ConceptShare. There’s a difference between collaboration and social networking. To me, collaboration serves an explicit purpose, where social networking is an implicit bonus. To some degree, though, often “social networking” is not a bonus. It carries a negative connotation because so many new applications thrive on the network itself, rather than treat it as the implicit bonus that it is (or should be). I mean, social networks aren’t products, after all. Then there’s collaboration, which is something to build an application around, in my opinion.
Just recently I redesigned the front-end of a site according to the demands of a client. In order to show the changes, I had to upload it to a test space on the server and email a few people the link with a description of the changes I had made. Then I got several emails back with likes/dislikes and more changes to be made. It’s tedious to collect emails that have gone through several people regarding thoughts on the same concept. That’s not really collaboration, but more of a pain in the ass. It was slightly more convenient than meetings, but by the same token, ended up being much less effective.
I don’t know how long ConceptShare has been around, but it appears to solve a big problem (remote collaboration) in a polished way. I won’t list out the features, here, but rather suggest you watch their demo video.
Everything around one concept should remain in one place. As much time as I spend reading online, I’m surprised I haven’t stumbled upon more applications that attempt to put a halt to the endless hunting for emails/attachments when collaborating. Personally, I’d much rather see applications that serve a purpose over those that do nothing but waste domain space, but maybe that’s just me.
I can’t help but to enjoy reading 37Signals’ design decisions. For those who don’t know, they’re just posts that provide a small insight into 37Signals’ design process and why they chose to do a particular something, a particular way. I’m sure most people who do the type of work that I do would agree that it’s interesting to peak inside of someone else’s design reasoning.
Garrett Dimon is an Information Architect who is working on a bug tracking system that he has appropriately named, Tracker. I’ve been keeping up with posts on the issue tracker, and I’m really impressed with some of the concepts and ideas. To save some hunting, here are the posts thus far:
Looking into other designs often help me to think outside of the box a little more, which I believe is important to keep that fresh, creative edge (assuming that I already had it, of course).
xtimeline is a site that allows people to visually recap an event in history by building a time line for it. I initially thought it was pointless, and maybe it is. But it’s kind of interesting to browse through some of them. It’s actually not a bad way to brush up on past events. It held my attention a lot longer than it probably should have. To list a few:
If I were back in eighth grade doing those tedious “research” reports, something like this would have come in handy. It’s too bad I knew more history back in those days than I do now.
I enjoy monitoring things over time (Google Reader trends, my investments, spending habits, etc). For me, golf adds one more thing to the list. However, there’s no real easy way to monitor my golf game over time. Especially since it has potential to span across years and years, adding up to hundreds (if not thousands) of rounds. To make things easier for me, I’ve decided to build an application I’ll call Golf Trac (excuse the cheap name, but it wasn’t that important to me).
Currently, it’s only in a sign-up state. I had originally planned on doing it for myself, but I know of at least a couple of people who would like to use it, which was reason enough to build it for others, as well. I don’t plan on having a “social network” around it, as the original reasoning is for those who want to track his or her own game. Of course, if I see some sort of need or reason to add social context, I may, but it’s better for me to start off with the basics. However, I have considered a mobile interface (to post scores as you play), but since I’m not really into mobile technology (yet?), that’s not a priority of mine.
So if you’re a golfer and think you might be interested, sign up to find out when it’s ready (curious minds are fine, too).
A friend of mine is working on a Rails CMS (called slate) at WVU. I’ve been following the development via slate info, as well as the screen shots on Flickr. I thought I’d take a minute to give praise to the work they’re doing.
First of all, I’m very impressed with the latest release. I personally think the interface is outstanding. slate does a lot of stuff, and from what I’ve seen, every section is intuitive and focused on the task at hand. The design itself is composed of mostly black, white, and shades of gray. This works well, because it’s easy to draw attention when you need to draw attention. For instance, by changing the sub-heading from black to bright blue, a user is subconsciously forced to pay attention—especially if that’s the only thing that’s bright blue.
I’ve never used slate, but I can tell there is an extreme attention to detail. The development schedule seems to be very realistic (even though I’m sure it doesn’t feel that way at times), which is why I think it’s turning into such a great application. There’s no “throwing it together,” so to speak. Every section seems carefully planned and designed down to the very last pixel, as it should be.
All throughout slate (again, from the screen shots) there is a brilliant use of space. Nothing is too cluttered (line-height really makes a difference). The typeface is very standard and somewhat over-sized, which is a good thing. The menus and options are clear, and they’ve gone the extra mile to make the entire interface very user-friendly.
It’s been fun following their development, and I look forward to reading about what’s to come in the future. Congratulations to Chris and Dave (those guys are the only two I’m aware of) on their hard work—it looks like it’s really paying off.
I came across the painless png plugin yesterday, but have yet to use it. If it works well, I’ll probably consider it a necessity for future apps, as that would make dealing with icons a whole lot easier.
I’ve been slow to adopt some of the things I see very useful today, but twitter is not in my adoption list. I just don’t get it. I gave it time, holding back my opinion just in case one day I would see the light, but I still don’t. It’s kind of cool when I think about the technology, but even that doesn’t make me want to ever use it. I keep reading about how it’s growing and growing—how come I don’t understand why it’s so popular? I just saw this on the main page: “eyelids drooping… 5pm… what the heck?” Hmmm… ok, whatever.
I’ve read, a time or two, things like “if you’re going to scale, you should probably move away from MySQL up to Oracle or SQL Server.” And for all I can argue, that may be true—but it might depend on your idea of scaling. The other day I read through a Flickr presentation on their Architecture (they’re using MySQL), and came across some very impressive stats (such as ~25,000 DB transactions/second). The presentation says a snapshot of db1.flickr.com shows…
I would consider that to be a reasonable scale. Oh, and keep in mind, that presentation was from 2004. They’ve probably doubled that since then.
Glancing through those slides has shown me how much I really don’t know about high-traffic application design. But that’s not too disappointing since I’m not-so-much interested in that stuff. Server issues and “vertical partitioning” a DB (whatever that means) doesn’t intrigue me near as much as the application itself. Of course, though (and thankfully), I won’t ever have to worry about an application experiencing over 50 million SELECT’s on one instance of a database cluster. But apparently, when properly configured, MySQL can handle it. I think I’d save the $25,000 it would cost for SQL Server, too.
Flickr is probably my most favorite web application I’ve ever used (“most favorite” doesn’t sound right, but you get the idea). Now that I’m really getting into photography, I’m realizing more of what it can do—which results in me loving liking it more and more. Then today (or maybe yesterday), Flickr released collections and a customizable layout. A collection is nothing more than a ‘set of sets’, but this is something I’ve been wanting for a long time. Now, not only can I organize my trips and vacations into sets, but I can have a collection of sets for Trips & Vacations.
The fact that you can associate a few sets with a collection isn’t that impressive (although very beneficial), but the way they’ve implemented it is impressive. The ‘organize’ section of your photos is where you can setup collections. Just drag your sets over to the collection of your choice, and viola, it’s that simple (you can also drag/reorder your sets within the collection itself). Then you can create a mosaic for that collection, choosing a nice blend of 12 photos from any of the sets it contains (those are also draggable). I think that’s awesome, and it works really well.
And to add in a little more, you can now specify a different layout for your main photo page. You can have small pictures with sets to the right, or small pictures with collections to the right, or large pictures with sets to the right, so on and so forth. There is a total of six layout options. I personally like having smaller photos with my recent sets to the right—the default view. But when I get a new camera, I’m sure I’ll be taking pictures at least 2-4x more than I am now, so I might decide that collections to the right would be a better fit. Either way, it’s nice to have the option. Kudos to Flickr for being perfect.
I am far from the party animal; in fact, I don’t drink at all. But I came across The Kegulator and thought I’d share. A good design, good interface, and if it’s anywhere close to accurate, I give it a thumbs up.
I don’t read Digg avidly, but I am a fan. I’m also fascinated by its algorithm (not that I know it). I did read about it before, and stumbled upon this reminder yesterday (and another from the comments). I learned a thing or two, and was, yet again, impressed to think about all that is considered for a post to make it to the front page. I never really thought about the speed of which a story gets “dug,” but that really does say a lot for its popularity. The fact that it’s not well-known as to how smart the algorithm really is shows how Digg employees care more about the content that floats to the top than promoting a smart, feature-rich system. It’s not just the number of “diggs” after all.
Here’s a scenario for you. Lets say you’re planning to build 8 Rails applications over the next 12-18 months. These applications must all talk to one another, but that’s a separate issue from the very first problem you encounter: the login. For user simplicity, among these 8 applications, the user(s) must have only one login. For instance, if the user registers with any one of the 8 applications, they are automatically “registered” for the other 7, but cannot have access until granted (either by payment or a higher power). How would you go about this? What’s the most efficient “best practice” in terms of a single sign-on solution in Rails?
This scenario fits in nicely with what I need to start at work. The two possible routes we’ve been considering are: 1) build a custom, external users web service to manage all of the registration and 2) use OpenID. The first solution sounds appealing, only I’ve never built this kind of solution before (an API), and I’m unaware of the things I should be forewarned about. I don’t really know where to start with developing an API, but that might be another post in itself. I’ve read a little bit about ActionWebService, but haven’t delved into it heavily. I’m hoping I can build the application as a stand-alone application (the user(s) management), then extract out some methods I want for the API, and worry about that at the end. But maybe I should set things up differently in the beginning. I just don’t know, yet.
I’ve also considered just using the same database for the users information, and having a custom Users model in each application that uses establish_connection to get to the users database, but that seems to repeat too much code. Maybe there’s a way to write a plugin to hold all of this code, but then when things change, I’d have to reinstall the plugin across all 8 applications. Plus, I’ve never written a plugin, either, so I don’t know what’s involved, or if that would even work for what I need.
Ultimately, we will want the ability to login using a username/password along with the option of using an OpenID. But I believe we’re going to start with username/password logins. Anyway, do you have any thoughts on how to provide a solid, single sign-on solution for approximately 8 applications written in RoR???
I know storage space is considerably cheap, but unlimited? Anyway, here’s a site that let’s you upload anything of any size an unlimited number of times: DivShare. It might be useful.
Maybe you were thinking this was going to be a tutorial or a methodology for good practice, but it’s actually quite the opposite. I agree that scalability is extremely important, but I don’t exactly know what it means to “build for scalability.” Well, I know what it means, or at least the point is made, but how do you do that? What would I want to do differently? I’ve read a number of times that you should “worry about your users once you get them; just set your app up for scalability.” It seems like it’s a hardware issue, but I’m sure it’s more than that. Maybe by building a service-oriented application, you can eventually host each “service” on a separate, dedicated machine to handle large amounts of traffic? I’ve looked it up and read a little bit about it, but nothing jumps out at me to claim that I know how to do it. Surely it’s more than optimizing SQL queries. Luckily for me I don’t have (nor am I involved with) an application that requires sound scalability.
If you spend a lot of time on a computer, keyboard shortcuts have probably become intuitive. The “shift + end” to select complete lines. The “alt + f + s” to quickly save your progess. And more commonly, the “ctrl + x” and “ctrl + v” to cut and paste. These are common among desktop applications; but now that some web applications are mocking desktop applications, keyboard shortcuts have found a spot there as well. When used for true benefit, I think keyboard shortcuts add a lot to an application. Take Google Reader for instance. There is a lot (for me) of content coming and going, and it’s tedious to use the mouse repeatedly. Luckily, they have an exhaustive mix of easy-to-use shortcuts. Especially useful: the j/k combination, with a touch of u. Use j/k to navigate next/previous, and u to expand to full-screen (good for the longer posts). There are many more if you’re interested. With something like a feed reader, I think it’s important to be able to get through feed’s quickly; these shortcuts definitely help. I think Rails has an easy way to incorporate keyboard shortcuts into an application, but I’m not positive on that.
See, this is the type of thing I sometimes don’t realize. I haven’t used respond_to in any of my applications, and I’ve implemented quite a bit of Ajax (not that respond_to is solely used for Ajax). And for the record, I’ve never attempted to write my very own REST web-service in Rails. I’ve requested other web-service’s, but I’ve never supplied an API. But it’s seemingly ridiculous to not include it in some of the things I do. You know, just in case. And if nothing amounts of it, at least I’ll know what needs done if I ever do need to do it.
There are two ways I’ve dealt with Ajax in Rails: the 1.0 way of render_without_layout and the 1.1 way of RJS. In either case I had an extra method (which means an extra template/view) to handle the Ajax response (I also wasn’t aware of xhr?). So, what resond_to is trying to tell me is that I can use the same method/action for regular post-back’s, Ajax request’s, and REST requests??? And not to mention it’s only 5 (or so) lines of code? That’s quite impressive, unless of course, I’m not stating things correctly. From all that I’ve read, I’ve somehow missed the boat on the respond_to option. I think I noticed it a time or two, but never dug deeper—it looks very handy. Are those three classifications (html, js, xml) the main usages with respond_to, or are there more?
Unless, of course, it’s executed. I just finished re-reading Getting Real (yeah, it’s that good), and I forgot about this. It’s an interesting point:
Awful idea = -1
Weak idea = 1
So-so idea = 5
Good idea = 10
Great idea = 15
Brilliant idea = 20
No execution = $1
Weak execution = $1000
So-so execution = $10,000
Good execution = $100,000
Great execution = $1,000,000
Brilliant execution = $10,000,000
Multiplying the two gives you your pillar of success. I suppose that’s why a lot of good ideas get flushed down the toilet: no execution. I recently read that MySpace is now worth $6 Billion. Would you consider that to be brilliant idea/execution? While the majority of pages on MySpace are ugly and unruly, I guess the execution lies within the freedom given to each member to make those pages ugly and unruly. Personally I think it’s the most obnoxious place on the internet, but apparently it’s working.
Once you’ve accomplish something, you feel comfortable doing it again. And why shouldn’t you? After all, you’ve already done it. And that’s exactly my problem. When it comes to programming I often feel so comfortable with something I’ve done already, I’ll do it again. And again. I’m not the best at exploring new alternatives; it can be hard to do something away from what you know already works. But the last thing I want to become is a developer who relies on the specifics of past experiences.
I think it’s safe to say my favorite language/framework (at this point) for the web is Ruby/Rails. So I naturally want to learn more about it, and how to master “the Rails way.” In an ideal state, along with the fact that I would have to be someone other than me, here’s what I would propose: develop a new mini-webapp every month. And if I were indeed someone other than myself, here are the requirements I would have:
Now, all I have to do is figure out how to become someone other than me, so I could actually do something like this. Really, I probably would do it if I had more time. And just in case I do, any suggestions for the first one?
37signals has established themselves on the web by creating very user-friendly project management tools, and by implementing them under the “less is more” approach. Now, I think they could build just about anything they wanted and it would be adopted by tons of people. Essentially, they know what “cool” is. They are indeed an interesting company, and I really enjoy reading their posts. Especially the new series, “Design Decisions.” They take a design decision they’ve made, break it down and explain why they’ve made it. It’s entertaining to read how the big-timers (although they’re a small company) contemplate a new design—even if it is just the menu of a page. I believe they’ve only posted two for the series so far (1 and 2). If you’re into web (application) design at all, you’d probably find it interesting to see how a really successful team breaks down a design.
Wasn’t it just today/yesterday when I was complaining about the things I didn’t like with Google Reader? Well, lo and behold, they’ve met my needs graciously. Last night, Google upgraded their reader and I’m thrilled with the new changes. Let’s review what I didn’t like, versus what’s new—shall we? Here’s the basic list:
Now that I’ve mentioned the basic list of issues I had, how does the new reader correct these things? Let’s take a look:
Solution to Problem 1: Get rid of the feed column entirely, and replace it with a subscription list. Not only a subscription list, but a sophisticated subscription list with collapsible folders and the ability to toggle between all feeds and updated feeds—much, much easier. Oh, and the list is constantly working for you by performing a consistent checkup on your feeds via Ajax. A nice touch.
Solution to Problem 2: A fancy little drop-down to add new feeds. When you subscribe to a new feed, you don’t leave your current location throughout the entire process.
Solution to Problem 3: Eliminate the feed preview before subscription. Really, this was unnecessary. Admitedly, I can see the value, but usually a person knows if they want to subscribe. I viewed the preview as an unnecessary intermediate step and I’m glad it’s gone.
Solution to Problem 4: Keep the feeds in an expanding container. I always hated reading long feeds beacause I had to scroll to the bottom of the page, sometimes losing complete site of the feed listing. The use of spacebar helped the issue, but it was still inconvenient. I usually just skipped what I couldn’t see, unless it was really interesting. Now feeds scroll inside of a container, allowing the subscription list to always remain visible.
Solution to Problem 5: Display a count of the new items per feed subscription. I probably get the most satisfaction from this upgrade. Not only are the feeds marked with a count, but they’re distinguished as bold (in case you want to view all feeds). Wait, I’m not done—there are counts per folder (or per tag), too!
Not only are my quirks corrected, but we have a few bonus features as well. Things like updated shortcuts, an addition of a “home” section to show what’s new (including the latest post from the blog), previous/next buttons for easier navigation, a “mark all as read” link, and an option to mark items as read simply by scrolling down the list. Not to mention the ability to toggle betwen “expandable” and “list” views, which might be familiar to all of those gmail users out there. If you think about it, a feed reader is like an inbox. Now you have the option to treat it like one. Plus, the UI has been carefully crafted in my opinion. Have you noticed the subtle difference between (in expandable view) a new item and a read item? I’m a sucker for the subtle things. Overall, I have to say, I’m impressed with this reader and it gives me more motivation to keep up with my feeds. I’ve come across several new things while writing this post, so I’m anxiously awaiting to find more of the new features that have slipped by.
At work, I’m helping to build a new application that utilizes ajax to the fullest. This is bar none the most ajax intensive application I’ve worked on. It’s awesome, though. I’m learning so much about Ruby and Rails. I knew I would if I were to do this stuff at work instead of trying to find the time between work, school, and hanging out with Amie. Anyway, this afternoon was the most severe case of ajax I’ve come across.
Sometimes it can be tricky to follow the variables and keep track of IDs and requests when you have multiple ajax calls without a page refresh. For instance, just today, I had to add the ability to post entries related to [a top secret something] and allow comments for those entries. Also, this is a multi-user application, so if the entry belongs to you, allow editing of the title and body, as well as your comments (if any) for that entry. Thankfully, Rails has tremendous support for ajax. This is all fairly straight forward, but the part I was having slight trouble with was if a user posted an entry, wanted to add a comment, edit the entry, add another comment, etc., all without refreshing the page (or upon return). Each time I came back from an ajax call, I had to keep track of the unique <div> IDs so the other ajax requests that were rendered in the previous response would still work and update the same locations as if it were a fresh visit. For instance, let’s say this happened without a page refresh: click to post a new entry (request 1), submit the entry (request 2), edit the entry body (request 3), view the comments (request 4), add a comment (request 5), edit the entry title (request 6), edit the comment (request 7), delete the comment (request 8), and finally, delete the entry (request 9). Essentially, that could happen. Even though it’s unlikely, it has to work just in case. It’s always those wacky situations that bite. So after tracing through the issues for a bit, it started coming together. I got it all worked out this afternoon (I still need some slight fixes on the comments) and it seems to be flawless so far. It always feels good to reach a good stopping point on a Friday, and it feels even better now that I have it commited in the repository :) Out of curiousity, what’s the craziest ajax trail you’ve had to follow?
Update: I fixed the comments tonight, and tested everything. It’s all working as planned. Sweet!
My security clearance is in the final stage. I don’t know how many stages there are, and considering it’s been nearly a year, the “final stage” doesn’t mean much to me. However, supposedly it’s going to be done in two weeks or so (it’s not the first time I’ve heard that). Before, I was ready to go just to rid myself of that project I WAS working on. But I’ve been switched over to another project until the clearance comes through, and it just so happens to be developing an application using Ruby on Rails. How nice is that? But my time is limited, unfortunately.
There are a lot of things I don’t do that I should when I develop (like use subversion), but I’m hoping I can pick up a few good habits before I head over to Lockheed. I’ve been staying somewhat involved in the project, simply because I love web applications and this one in particular seems pretty cool. I never really worked on it much, but I had several conversations concerning its goals and potential. I’m excited. I’ve been given total control over the interface design, which I should be able to knock out rather quickly. And as always, it will be tweaked throughout the process. That’s the nice thing about working for a small business… creative control. I’m now hoping Lockheed drags their feet on the clearance, but knowing my luck it will come through tomorrow.
Let’s say you are building an application for a general audience, such as teachers. Well, in order for your software to be successful, you should find out what teacher’s like, as well as what they’re used to. Or should you? Often a client (or audience) has a massive impact on business decisions. And to play it safe, maybe that’s how it should be. But as you probably know, sometimes the client/audience isn’t as tech savvy as you would like, or maybe even expect. This can make things difficult.
An honest assumption might be most teachers aren’t keeping up with the latest technology. While you have insight into what’s better, they might not “get it.” Yet. Just like email, many of the so-called current trends are here for the long haul, too. Being the web specialist that you are, do you put it on them anyway? Or do you hear them out on things like “Why would I want to use email?” or now “Why would I ‘tag’ when I can search?” When is it alright to do what’s best in your own eyes? Those who get it, get it; those who don’t, eventually will. Is it fair to take on this type of attitude when developing? How much should you worry about your audience understanding your cutting edge application? If passion is a large part of making a good product or service, it seems like you should build what you want and worry about the audience later. Then again, that can come off as immature.
The way to success is to make something different. There’s no reason to reinvent the wheel – new ideas, new methods and new technologies are what drive the web today. But I’m never really sure how far you should take it, before it starts to alter the clarity of its purpose. I guess you could always refine your audience to only the “tech savvy teachers,” but then you might have less users. Where do you draw the line? Anyway, I was just thinking about a recent situation and wondering how/when you go with what YOU think is best vs. the others involved, generally speaking.
I use web-based documents every day. For general, random needs, I use 37signals’ Writeboard. For more sophisticated, organizational word processing needs, I use Writely. I’ve been using Writely long before Google bought it, but never daily until now. It really is a great way to collaborate and log ideas. I even use Writely for school. I would much rather have a Writely document than a 5 lb. notebook that get’s piled into the crate on my closet floor. I never thought I would be one of those who takes notes on a laptop, though. It’s also a good tool for project collaboration… much better than sorting through the multiple revisions of a document floating around in my email. Of course there are downfalls (like diagrams), but I can usually work around those issues. To me, the benefits exceed the drawbacks.
Being in the SE program, both creativity and design are a large part of our assignments. I think webdoc’s work out extremely well for preliminary design, because I can keep my thoughts and ideas logged as they come to me, at any time and any place. Although I am a bit of a web-junky, and maybe I reason it out to be useful, but I’m really beginning to break away from the standard desktop approach to files, specifically documents. To me, it’s just easier.
When Newshutch first came out, I was amazed. I immediately exported my OPML from my current reader, and started using it. Then, it’s wonderful interface became known by the guys at 37Signals (they have an awesome audience), and they posted about Newshutch on their blog. The traffic to Newshutch immediately exploded and their server started overheating. It became entirely too slow for me, so I jumped over to Bloglines until they got things under control. Bloglines is really fast, but it’s not very clear on navigation and I find myself often wondering, “What does this do?” The Bloglines interface needs a lot of work. Anyway, I decided to check up on Newshutch to see how they were coming along, and not to my surprise, they’re running very smooth. A lot of their complications were due to a lack of optimization of their SQL statements, which was taking way too long to get the data for all of those new users. I believe they now have a dedicated server just to host MySQL, and they’ve tweeked all of their queries to be much more efficient.
So, I’m making the switch back to one of the few readers I can actually tolerate. There are still a couple of things I’d like to see added on to Newshutch, but I’ll save that for another time on a different day.
2008 by Ryan Heath | Get In Touch
