Archive of RubyForge sup-talk mailing list
 help / color / mirror / Atom feed
From: rogutes@googlemail.com
To: Anirudh Sanjeev <anirudh@anirudhsanjeev.org>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] New website design for sup - preview
Date: Mon, 12 Apr 2010 01:47:00 +0300	[thread overview]
Message-ID: <20100411224659.GA2411@urvas> (raw)
In-Reply-To: <1271014668-sup-4377@deepthought>

Anirudh Sanjeev (2010-04-12 01:42):
> Hi,
> 
> I'm sorry, I don't buy the "intelligent/experienced/developer users don't
> care about the frontend design" idea.

But the frontend of Sup is the ncurses client, isn't it? I do care about
my e-mail client's UI, I care less about its website.

<..snip..>

> Excerpts from Rogutės Sparnuotos's message of Mon Apr 12 01:03:58 +0530 2010:
> > Why is the original site bad? I think that it provides more information
> > and takes less vertical space. Only the screenshots could be bigger
> > (and perhaps 4 instead of 6?).
> Why is vertical space bad? I am not saying that the old website is bad. It
> isn't immediately obvious what the exact _killer functionality_ of sup is,
> unless you take a very close look.

_Wasted_ vertical space is bad: the more you see of the real content, the
faster you skim through.

<..snip..>

> > 2. First 700px of the page show nothing useful, except for a screenshot
> >    and big letters.
> Have you heard of "minimalism"? There's a reason why clean desks and rooms
> are more enjoyable than cluttered dirty ones. It's not a developer/end-user
> thing it's a human thing.

Sup's home is a very good example of HTML minimalism. It has minimal
design, too. And is enjoyable. A matter of taste, I guess.

Your proposed list of features seems to enforce structure by design, but
it fails to carry out its mission by succumbing to javascript fun. But
yes, the current website could put some kind of emphasis on the features
section.

<..snip..>

> > As for the GMail guide, wouldn't it be very useful in the wiki?
> It's been on the wiki for four months. I wrote it. It's very hard to find
> on the wiki.
>
> I hope this again, reinforces my "don't make everything harder to find just
> because you target advanced users" belief. Instead of taking the most
> important information and putting it somewhere you'll have to google around
> for, put it right where people would expect to find it.

The point is that the wiki, not the homepage, needs a facelift. And the
homepage could list the most visited pages of the wiki.
I've seen the GMail guide in the wiki prior sending my mail and I still
feel that such a guide is more appropriate there.

> tl;dr: It has nothing to do with a target audience. Saying a more pleasing
> website does not appeal to hackers is mild stereotyping, and I am not sure
> whether to be flattered or offended.
> 
> I've seen this issue a lot before - we write awesome, incredible code and
> put it up on a wiki, and don't put in even a hundredth of effort doing
> design as it's not intellectually satisfying. So you've got great projects
> which fail to distinguish themselves from the crowd - on wikis and github
> accounts around the world, there are great projects just like sup nobody
> takes notice of.
> 
> And then you wonder why nobody is interested in your project. It happened
> to me and my projects as well.
> 
> What I'm hoping is that if someone visits the sup site, they should be
> excited and interested to try it out - and having something mildly
> professional and something that seems to have some effort put into it will
> surely help. More people trying it out is better for all of us.
> 
> This is just a proposed facelift. The devs decide what happens and what
> doesn't. I just posted to get some constructive feedback and I'm sure I'll
> get some real soon.

I was trying to compare the current website with the proposed one,
criticizing the latter. Even if you didn't make the design, you have
chosen it. I found the colors ok, but I didn't like non-degrading
javascript and the amount of vertical space wasted. Next, instead of
copying the content, you replaced it with your version. If yours would be
chosen as final, I would mourn the current one, so I raised my points
about it.

Anyway, our dialogue looks incompatible: you seem to be worried about
projects lost in web space, whereas I am worried about the trends of the
web. One more issue adding to the incompatibility might be the destructive
tone I initially chose. Sorry about that.

-- 
--  Rogutės Sparnuotos
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk

  reply	other threads:[~2010-04-11 22:47 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-11 15:54 Anirudh Sanjeev
2010-04-11 16:15 ` Ramkumar Ramachandra
2010-04-11 16:39   ` Ben Walton
2010-04-11 17:43   ` Anirudh Sanjeev
2010-04-11 19:33 ` Rogutės Sparnuotos
2010-04-11 19:56   ` Michael Stapelberg
2010-04-11 20:12   ` Anirudh Sanjeev
2010-04-11 22:47     ` rogutes [this message]
2010-04-12  5:30       ` Anirudh Sanjeev
2010-04-12  7:25   ` Tero Tilus
2010-04-11 20:47 ` Philipp
2010-04-11 21:14   ` Anirudh Sanjeev
2010-04-12  7:56   ` Tero Tilus
2010-04-12  6:53 ` Tero Tilus
2010-04-14 12:34   ` William Morgan
2010-04-14 12:32 ` William Morgan
2010-04-14 18:55   ` Anirudh Sanjeev
2010-04-14 18:30 ` Michael Stipicevic
2010-04-11 16:23 Michael Stapelberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100411224659.GA2411@urvas \
    --to=rogutes@googlemail.com \
    --cc=anirudh@anirudhsanjeev.org \
    --cc=sup-talk@rubyforge.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox