I don't really know what you mean. I made the font slightly larger (although it is configurable) in order to give it visibility and readability on larger screen resolutions. It's 12pt Segoe UI.
Oh, I wasn't referring to your program but the Adobe Air programs. Compared to everyday other programs, most of them have small fonts and buttons.
The problem I found was that they take up too much screen real estate and weren't "Always on top". I wanted something that I could tweet quickly and just leave there without any real effort.
I'm not sure what you mean here. .NET? Something else? It's meant to simply sit there unobtrusively and let you tweet quickly and easily. Not more. Not less. I don't know how it's not a simple infrastructure.
.NET 4.0 was unnecessary. I could have easily done it in .NET 2.0, but I wanted to just play around with .NET 4.0 and have a quick look at it. If I were to take the program very seriously, I would have done it in .NET 2.0, and that would be invisible to virtually everyone as .NET penetration there is extremely high.
Basically, it was me just killing 2 birds with 1 stone to save time.
The .Net issue is basically summed up as a question of why does a simple program need another additional component to install.
For the most part, people tolerate Adobe Air clients because they were the early entries if not the preferred model for complex "simple" Web 2.0 services.
The simplicity issue is connected with this post:
At the end of the day though, the program fails because it doesn't simplify the process for Twitter users.
Twitter users especially the busy ones are primarily discussion seekers. They are not as much bothered by how to broadcast a tweet as much as they fear missing out on a participating in a popular discussion or finding an interesting link and commenting on it while it's hot.
This isn't to say they want an all-in-one complex as molasses product but it is like designing a program around the mindset of Facebook users but doing it for Twitter instead when most of the needs of those using Twitter are different.
I think you have different expectations than what the program sets out to do.
The program is not supposed to be for "Twitter users" at all. It's for "people that want to tweet", but couldn't be bothered to put in any effort.
It's a subtle difference, but an important one. Twitter users will tweet anyways. This isn't for them. This is for the guy that would like to tweet, but just can't be bothered to fart around with a browser and clicking and signing in and tabbing, and clicking in input fields and clicking a Submit button. This is for the guy that wants to type and tweet, and not anything more than that.
I don't think it's different expectations and no, Twitter is one of the few things that doesn't have users that will necessarily tweet. For the top submitters this is true but for the middle of the road Twitters, it's based on incentive. That's why lots of sites still have re-tweet and follow me on Twitter buttons.
It's more the dilemma of a review of an application claiming to be a Twitter client.
Now if your client allows for Twitter users to filter and find posts and reply to them while maintaining the same level in everything else, it all fits.
When you remove a component of what makes Twitter function though, it's more like a Twitter broadcaster but it can only be considered a client in the barest sense of the word.
As you say, it's a subtle but important distinction. The issue though is really where the line is set forth.
Even for guys who just want to type and tweet, there has to be an understanding of where their goal lies or how their needs might evolve.
Without a way to at least discover @replies and respond to DMs, this program can't fully fulfill the qualities of a "client" and so as a reviewer, it's a hard line that needs to be drawn somewhere in order to at least be a review.
It's not really my expectations as I'm one of those guys who fall under "guys that just want to tweet and type". That said, there are many different examples even under that minimal category. Category number 1 would be communicating with people in those rare times. Category #2 would be typing in reply to others or as a retweet.
Very rare is it for Twitter users to stick to one area. A person who just broadcasts for example may still participate heavily in DMs.
A client is not always technically known as equivalent to a browser but a Twitter client holds a unique goal of keeping users from a site by fulfilling the basic needs using said client.
Even your client aims to alleviate the screen estate and mouse clicks of other clients and site extensions of Twitter.
But that's the chasm a review has to cross: Between two perspectives, the goal of the developer and the needs of the userbase, how do you connect and communicate the fact that you at least understand both sides but the premise is just insufficient currently?
It's much easier to err on trying to explain the basic needs of the user and let the developer decide whether what the review writes is warrant of a change.
It's also very easy nowadays to right click on Google Chrome and create an application shortcut to send you right into a Twitter page and sure you may lose the power of url shorteners but it's not like the program auto-converts the url for you and some of us don't use Bit.Ly when there are even shorter url shorteners out there.
Browsers are cumbersome and take up screen real estate. I wanted to avoid a browser at all costs as they are just slow. Using a mouse is also very slow, and using TAB to get into the right input field in a browser is extremely time consuming.
But it does convert URLs if you want it to. I thought it would be presumptuous to have it do it automatically. (CTRL + ALT + U)
True but since you have a url shortener built in, you are kind of sending a message that a browser still has to be opened.
This is setting aside the differences between a application shortcut Twitter page that is more meant to be quickly closed to the point that the screen real estate is only bothersome as the user is typing a tweet and the issue that there are still many compact ways to tweet. Obviously not as compact as this program is but the browser is directly connected to link sharing unless you assume all users are also heavy copy pasters who store or memorize urls within non-browser applications.
As far as automatic url shortening, I feel that's intrusive too because they often don't mesh well with text but there's really no sense in not auto-shortening a url aside from not wanting to use a specific url shortening service.
There's no inherent benefit from having less free text space to type on Twitter's already small character limit.
Not at all.
If I'm guessing right, I think that what you were sort of expecting would be best done as a browser plug-in.
No, not really. As a guy who rarely tweets on Twitter and fall into the realm of just typing to tweet, I do desire an application like this and I like to think I have a close understanding for why people would want this because I want this too.
Does Plurk have many users? This is the first I've heard of it.
As for Gmail, it would be drop dead simple to do, but I don't really see a point to it as it's using Gmail for what amounts to a highly-specialized, odd use for it. There are better ways to store notes.
True. The whole post it to Gmail is more of a specialized hack for people wanting a fully backed up easy to search for taggable note collection which can also easily support reminders.
Plurk's story is pretty much cut and dry nowadays. Back then when the fail whale came, people moved to Plurk and it got a boost.
Some stayed because Plurk was a better way to monitor and have conversations. It wasn't as big as Twitter but there were many users and there were many hopefuls that it would eventually have a client. Instead all they got was a variation with Plurk mobile's ui which is not only bad looking but doesn't represent the Plurk nor the Twitter feel that well.
For the tl;dr version, see Plurk's problems in this post: http://plurkable.com...urk-not-growing-why/
What Plurk is notable though is that due to the design, it mainly caters to either broadcasters or conversation seekers. It's not like Twitter where you draw the line between re-tweets, DMs and tweets.
In Plurk, people are very evident both ways. For the most part, the broadcasters don't need to worry about failing to monitor a @reply or DM because Plurk works more like a micro-threaded forum where you can just check up on the main site and people will still be notified if any new replies exists under a Plurk you make.
The name is meant to be long and humorous as a contrast to the shortness and ease of the program itself.
At the end of the day, it's a very small program, with a specialized purpose, and not a major product. I don't plan on putting any real marketing effort into it. It will never be massively popular, and will never make me rich or famous.
To frame the program in a different perspective, it solves a specific "pain-point". Take for example my DNN Keep Alive program; it solves a very specific problem on a small scale.
In planning software, my approach is to find a pain-point, then solve it. Very little of what I actually write ever gets released (most of my pain-points are extremely esoteric and have no broad consumer/corporate appeal). The pain-point that T3 solves is specific, and obviously not for everyone. I decided to make it available as I figured that there would be enough people like me with that specific concern to make it worthwhile.
To be honest, I simply wouldn't tweet at all without it. Other clients were simply too large or complicated, and I refuse to use a browser for it. (I find browsers are rather clunky things -- they try to be everything to everyone and fall short quite often.)
True but to refer to your statements of website design as an analogy, there's a difference between marketing and ergonomics.
In this case, even if you don't market it, it may help if people can re-discover or find it via Google in a much easier manner.
It's not like you couldn't keep the long version of the name as long as it has a shortened nickname.