Bad OS/X First Impression - Java file browser

Hi Andy,

> I nearly rejected SmartSVN immediately and I suspect many other people will, on OS/X,
> because practically the first thing you have to do is use the Java file browser.

I guess, you mean the *directory* chooser instead of the *file* chooser.

> I don't know if you can do anything about this but it presents an EXTREMELY hostile view
> of the filesystem compared to normal Mac programs.
>
> In particular:
> 1) it starts at the system root instead of ~

I've fixed the directory chooser embedded in the "Add Project from
Already Checked Out Working-Copy" listener, which now should select the
home directory for unix-like OSs by default.

> 2) it shows directories starting with . which should be invisible.

We will hide them by default and add a toogle action to show them. Would
this be OK for you? BTW, with OS X' file chooser I seem not to have the
possibility to show hidden files on demand - this is IMHO much more
worse than showing them by default.

> The GUI looks pretty good once you make it in there but I fear you may be losing a lot of
> potential customers.

Do you really think, we are losing a lot of customers just because of a
file/directory chooser?

> Possibly helpful links:
>
> http://www.devworld.apple.com/samplecode/FunWithFileDialogs/index.html
>
> http://www.randelshofer.ch/quaqua/download.html
> - drop in solution!
> "Quaqua user interface delegates closely look and behave like their native counterparts.
> Complex user interface components, such as JFileChooser and JColorChooser, are close
> enough to make end users feel comfortable with them.";

As you may already have noticed, our applications make use of Quaqua
look and feel, but an older one because newer ones look more worse.
Also, its *file* chooser is used instead of our own one which is used on
other platforms and better matches the application's look and feel than
native ones.

--
Best regards,
Thomas Singer
_____________
SyntEvo GmbH

Andy Dent wrote:
> I nearly rejected SmartSVN immediately and I suspect many other people will, on OS/X,
> because practically the first thing you have to do is use the Java file browser.
>
> I don't know if you can do anything about this but it presents an EXTREMELY hostile view
> of the filesystem compared to normal Mac programs.
>
> In particular:
> 1) it starts at the system root instead of ~
> 2) it shows directories starting with . which should be invisible.
>
> The GUI looks pretty good once you make it in there but I fear you may be losing a lot of
> potential customers.
>
> Possibly helpful links:
>
> http://www.devworld.apple.com/samplecode/FunWithFileDialogs/index.html
>
> http://www.randelshofer.ch/quaqua/download.html
> - drop in solution!
> "Quaqua user interface delegates closely look and behave like their native counterparts.
> Complex user interface components, such as JFileChooser and JColorChooser, are close
> enough to make end users feel comfortable with them.";
>
> regards
>
> Andy
>
>
>
>
>
>
> Yahoo! Groups Links
>;
>
>
>
>

Messages in this topic (2) Reply (via web post) | Start a new topic

.

On 11/13/06, Thomas Singer (SyntEvo) < thomas.singer%40syntevo.com">thomas.singersyntevo.com> wrote:
&gt;
>
&gt;
>
>
>
> Hi Andy,
>;
> > I nearly rejected SmartSVN immediately ...
> > because practically the first thing you have to do is use the Java file
> browser.
>
> I guess, you mean the *directory* chooser instead of the *file* chooser.

yep, my sloppiness in description, compounded by the fact that OS/X
has packages which are implemented as directories but look like single
files in the normal file selector.

> > 2) it shows directories starting with . which should be invisible.
>
>; We will hide them by default and add a toogle action to show them. Would
>; this be OK for you?

I think so

> BTW, with OS X' file chooser I seem not to have the
> possibility to show hidden files on demand - this is IMHO much more
> worse than showing them by default.

I'm not sure I agree.

There are many ancillary files, resource forks and "desktop info"
associated by having dot prefixes.

The assumption in the OS/X UI is if you are knowledgeable enough to
really need to open an invisible file that you will do so from the
terminal.

Due to differences in conventions from Windows, in particular, the
need to view "invisible items"; in a desktop view is much smaller - I
can't actually think of a legitimate case off-hand.

> Do you really think, we are losing a lot of customers just because of a
> file/directory chooser?
Yes.

I have been developing software for over twenty years and much of the
last decade has been in customer-oriented, shrink-wrap software. I
have also spent a lot of time studying usability and human factors and
some time studying marketing (in case I ever get that killer app
finished). I'm not boasting, just trying to reinforce my opinions as
coming from a lot of thought over many years .

My overwhelming conclusion is that most product developers VASTLY
underestimate how easily people are turned off, especially when it is
something being evaluated on the net.

I think the psychology is a mixture of:
1) "if they don't care about X then how can I trust them to care about Y"

2) "anything I download and test has N seconds to either catch my
interest or give me an excuse to not spend any more time thinking
about it", where N is proportional to
a) how long it takes to download on my connection
b) how I found the product, particularly if I found it by accident and
had a look as an impulse
c) the number of perceived choices
d) the quality of the alternatives, in particular if there is a pool
of moderate alternatives (as for svn GUI's on Mac) then you might find
people expecting your product to be no better - all they need is an
"excuse"; to label it as "just another svn UI with rough edges";.

Once people have labeled a product with a rejection like the above,
they need a much larger positive reason to try it again.

I think this is the same psychology as Jim McCarthy talks about in
"Dynamics of Software Development" in his essay "Don't Flip the Bozo
Bit'.

http://www.amazon.com/phrase/bozo-bit

Messages in this topic (4) Reply (via web post) | Start a new topic

.

Hi Andy,

&gt;> > 2) it shows directories starting with . which should be invisible.
>> >
>> > We will hide them by default and add a toogle action to show them. Would
>;> > this be OK for you?
>
> I think so

OK, I've made some changes: when "show hidden entries&quot; is unselected,
directories starting with periods will not be shown (for all unix-like
systems) and .app-structures are empty (for OS/X). When "show hidden
entries&quot; is selected, all the directories starting with a period are
shown with gray icon and one can dive into .app-structures (all content
is gray). Would this be what you expect?

BTW, should directories with a trailing tilde also be considered hidden
or just the directories starting with a period?

--
Best regards,
Thomas Singer
_____________
SyntEvo GmbH

Andy Dent wrote:
&gt; On 11/13/06, Thomas Singer (SyntEvo) < thomas.singer%40syntevo.com">thomas.singersyntevo.com> wrote:
&gt;>
>;>
>>
>&gt;
>&gt;
>>; Hi Andy,
>;>
>> > I nearly rejected SmartSVN immediately ...
>&gt; > because practically the first thing you have to do is use the Java file
>> browser.
>>
&gt;> I guess, you mean the *directory* chooser instead of the *file* chooser.
>
> yep, my sloppiness in description, compounded by the fact that OS/X
> has packages which are implemented as directories but look like single
&gt; files in the normal file selector.
>
>
>
>> > 2) it shows directories starting with . which should be invisible.
>>
>> We will hide them by default and add a toogle action to show them. Would
>;> this be OK for you?
>
> I think so
>
>> BTW, with OS X' file chooser I seem not to have the
>&gt; possibility to show hidden files on demand - this is IMHO much more
>> worse than showing them by default.
>
> I'm not sure I agree.
&gt;
> There are many ancillary files, resource forks and "desktop info"
> associated by having dot prefixes.
>
> The assumption in the OS/X UI is if you are knowledgeable enough to
> really need to open an invisible file that you will do so from the
> terminal.
>
> Due to differences in conventions from Windows, in particular, the
> need to view "invisible items"; in a desktop view is much smaller - I
> can't actually think of a legitimate case off-hand.
>
>> Do you really think, we are losing a lot of customers just because of a
>>; file/directory chooser?
> Yes.
>
> I have been developing software for over twenty years and much of the
> last decade has been in customer-oriented, shrink-wrap software. I
> have also spent a lot of time studying usability and human factors and
> some time studying marketing (in case I ever get that killer app
> finished). I'm not boasting, just trying to reinforce my opinions as
> coming from a lot of thought over many years .
>
> My overwhelming conclusion is that most product developers VASTLY
&gt; underestimate how easily people are turned off, especially when it is
> something being evaluated on the net.
>
> I think the psychology is a mixture of:
> 1) "if they don't care about X then how can I trust them to care about Y"
&gt;
> 2) "anything I download and test has N seconds to either catch my
> interest or give me an excuse to not spend any more time thinking
> about it", where N is proportional to
> a) how long it takes to download on my connection
> b) how I found the product, particularly if I found it by accident and
> had a look as an impulse
&gt; c) the number of perceived choices
&gt; d) the quality of the alternatives, in particular if there is a pool
> of moderate alternatives (as for svn GUI's on Mac) then you might find
> people expecting your product to be no better - all they need is an
> "excuse" to label it as "just another svn UI with rough edges";.
>
> Once people have labeled a product with a rejection like the above,
&gt; they need a much larger positive reason to try it again.
&gt;
> I think this is the same psychology as Jim McCarthy talks about in
> "Dynamics of Software Development" in his essay "Don't Flip the Bozo
> Bit'.
>;
> http://www.amazon.com/phrase/bozo-bit
&gt;
>
>
> Yahoo! Groups Links
>;
>
>
>
>

Messages in this topic (6) Reply (via web post) | Start a new topic

.

El 13/11/2006, a las 17:52, Thomas Singer (SyntEvo) escribió:

> BTW, should directories with a trailing tilde also be considered
> hidden
&gt; or just the directories starting with a period?

Normally a trailing tilde means the file is a backup. It shouldn't be
hidden.

Messages in this topic (7) Reply (via web post) | Start a new topic

.

Thomas Singer (SyntEvo):

>Do you really think, we are losing a lot of customers just because of a
>file/directory chooser?

Definitely some. Some mac users don'y like real basic apps for example.
It's really because so many developers stick so closely to the Apple
interface guidelines that those that don't kind of stand out.

Things like "open" being command-P instead of command-O was noticeable
when I started using SmartSVN.

The comment about the filesystem showing all the hidden files is valid,
and I would suggest on OSX that it was a preference with the default to
NOT show hidden directories. Anything that you can do to make SmartSVN
more like a mac interface would probably make a far better initial impression.

I don't know anything about Quaqua but the interface looks 100% MacOSX
in the following image ...

<;http://www.randelshofer.ch/quaqua/images/quaqua_metalworks.png>

... I'm guessing it's not possible to carry that right the way through
SmartSVN?

That said, SmartSVN is IMHO far and away the most powerful SVN slient
available to Mac users.

>BTW, with OS X' file chooser I seem not to have the
>possibility to show hidden files on demand - this is IMHO much more
>worse than showing them by default.

Anyone who needs to mess with hidden directories probably knows how to
use a terminal. I think it's better off! There are a bunch of
applications that will show them such as PathFinder. Remember the Mac
community moved to unix - there are a lot of people who've never even
seen a hidden file

--
Simon Troup
Digital Music Art

Messages in this topic (8) Reply (via web post) | Start a new topic

.