Re: Fwd: Re: [Setup-tool-hackers] Similar frontends?



You raise a very good point about support via companies. Ex. they don't want to
give two sets of instructions. However, so long as everything is named the
same, everything is within context, and each UI groups the same configurations
together with teh same phrases, things will be just fine. This does not mean
that the two UIs have to be identical though. Little things like icons, pretty
images to the side, exact arrangement of the widgets, etc... isn't a big deal.
The content is the important issue. Ex. click on hosts, click on add, enter
blargh blargh, hit apply, etc..... can be identical for each UI but have a
different style at the same time.

David Joham wrote:

> Hmmmm,
>
> As one of the "every other hackers" that is a GUI expert, I disagree
> strongly with the idea that the front ends could be different with no loss
> in functionality. Here's why:
>
> Our target audience is *not* developers. Our target is end-users and 3rd
> party application developers. These people need consistency. One of the
> points brought up in this list before was companies waiting to see who (KDE
> or GNOME) would win the "war" to see who they would support before they
> shipped product. This configuration GUI will be a very visible and important
> piece of any KDE or GNOME installation. People and companies will use and
> make reference to it all the time. This project will do nothing to solve the
> perceived issue of incompatibility if someone like Cisco has to include two
> separate sets of instructions to install their product.
>
> I'll address the issues brought up by everyone below....
>
> <<Both have different styles. Besides, since when was the goal to make gnome
> and kde similar? The goal is to make gnome and kde intuitive.>>
>
> Intuitive to who? Developers? Hackers? In that case, why not stick with the
> simple Perl scripts and write the XML to stdio by hand? Our audience is
> broader than that. It's not intuitive if it is significantly different
> between desktop environments.
>
> <<The backend is the key issue. The users will never see the backend... >>
>
> You made my point for me in your second sentence :) To the developers of
> this project, of course the backend is the most important. However, to the
> users, they couldn't care less. They just want it to work. And they don't
> want to have to figure it out twice. Or have to write "If you use KDE, click
> on the KSetYourIPAddress Tab, for GNOME click on GIPSetAddress"...
>
> <<Plus every other hacker is a gui expert.>>
>
> I guess you're right :)
>
> <<trying to make the GUI interfaces similar is going to trigger endless
> discusions about something that is artistic in nature.>>
>
> Then might I suggest separate mailing lists so the developers don't need to
> concern themselves with something that isn't important to them. That should
> clear that issue up in a heartbeat.
>
> ---
>
> OK, I'll give into the reality that in the real world the interfaces will
> not be identical. However, I believe that we would be really hurting both
> projects if we didn't at least try. If it doesn't work, well then as before
> nothing is really lost. But if it does work, well then think of how much
> further along we will be.
>
> I guess I'd also like to add that I believe that this project can become
> significantly more than just a setup tool project. Assuming that we can get
> this system working for the basics, why couldn't we then extend the project
> to setup Apache, BIND or any one of a number of different systems. The
> architecture would be the same. I'm thinking of a centralized place to
> configure most of what can be configured on your *nix* box. Of course this
> is in the future, but I believe it is important to have a vision of where
> you want to be in a year or two when starting projects of this nature.
>
> Thanks for listening,
>
> David
>
> _______________________________________________
> setup-tool-hackers maillist  -  setup-tool-hackers@helixcode.com
> http://lists.helixcode.com/mailman/listinfo/setup-tool-hackers




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]