tools - best way to design instead of programming?
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
tools - best way to design instead of programming?
I come from a programming background but I would really like to improve mu design skills.
What is the best way to go about designing/authoring websites?
I have used Kompozer before and Bluefish but I'm not sure how you draw the line between the HTML aspects + CSS and the programming parts.
Are there any sites dedicated to "fashionable ideas" in modern websites?
I tend to use templates from Wordpress, Joomla, Drupal and as good as these are, they lack a bit of finesse.
qwerty, I'm in the same boat as you
You could use GIMP to make the graphics. Linux web editors are NOT upto the level of Dreamweaver, so you might end up with a website that looks like it's been made by a geek
Since you're in the UK, you could contemplate a formal COURSE if you're interested - if I remember correctly Bournemouth and Univ. of Leeds have undergrad courses on the subject.
Check out www.netdiver.net (now obsolete), and caroleguevin.com for the PINNACLE of *design*.
I've been slinging bits and bytes since 1969 and the basic rules have not changed in all that time. An olde addage says, "You cannot automate a mess." This saying is meant to highlight the need to understand what is going on and know the rough edges, tar pits, and dragons of your processing needs.
What do you want to do?
What must the software do to support what you want to do?
Identify software you have vs. software you must create.
Which hardware do you need to run the software you need?
Identify the hardware you have vs. the hardware you must acquire.
The first step, What do you want to do?, is covered today with what are called Use Case or User Story documentation. There are numerous references available online.
The second step, What must the software do... takes details from the Use Cases and adds look-and-feel, forms and fields, data and processing to deliver the desired end-user experience. For web applications, I like to create a set of story-boards as a "presentation." You might use LibreOffice Impress to make slides unless you are comfortable writing xHTML.
Remember that any application includes not only what happens on-screen <--> server(s) but also includes whatever the end-user -- the loose nut in the operator's chair -- brings to and takes from a session with the application. For example, they must gather model number and serial number details for a customer service application. In addition, there is a similar take-from and bring-to on the back end of your server(s). For example, someone must load and maintain the product catalog of an e-commerce application.
Good luck, and keep us posted on your progress,
~~~ 0;-Dan
Last edited by SaintDanBert; 12-14-2011 at 12:11 PM.
I agree. Except it isn't "what you want to do" but "what is required". Everybody knows the "form follows function" mantra but regardless of that a lot of people fail to understand why design on its own is overrated (simply because it still sells). Unless you're showcasing your portfolio or freestyling design should always support and enhance the business. My litmus question always is "What does the customer want?" (The second question would be "How many steps does it take to complete the transaction?") Anything that doesn't answer that question only shows to prove the team didn't understand the business, anything that distracts, makes doing business harder or even impossible is out, no matter how much blood, sweat and tears were spent on the "design".
In short: the keyword is "usability" and when you say usability you (should!) think Jakob Nielsen.
As far as the designing process itself is concerned one of the worst things you can do is to use a personal computer: its interface distracts and does not allow you the amount of freedom you need and it can not keep up with speed of thought anyway. Did Antoni Gaudi use a PC? Charles Jeanneret (Le Corbusier)? Raymond Loewy? Sure you will need to find one or more places that match your thinking processes, sure you will need to develop your own shorthand but in the end pen and paper are all you need to start things going.
i rarely see a website programmer who has good design skills, and a rarely see a good designer who can code.
in my days of working with web content i was doing programming and the design guys were busy doing layouts and click-through flows on whiteboards and programs like photoshop and illustrator. design guys were worried about look-&-feel while the coders were worried about how to exchange data between the UI and backend "stuff", etc.
and today's websites vary quite a bit, from those that do heavy backend processing to those that are all show. the latter seem to be those generated by tools like dreamweaver and flash templates, kinda those drag-&-drop tools.
imho, if you want to learn design then "website" is not the thing to study, design is, etc. learn design and then apply that to whatever (boat sail, billboard, bumper sticker, vacuum cleaner, website, etc).
I agree. Except it isn't "what you want to do" but "what is required". ...
If you think this through completely, you will find that "what is required" is a subset of "what do you want to do"
I want to visit Portland, Maine and I live in Texas.
I could walk, bicycle, motorcycle, drive, bus, train, or plane.
Once I get there, I could stay a day, week, month, or relocate permanently.
Before doing much else, I must decide how I want to travel and how long I want to stay. Each of those decisions creates the need for other decisions about other I want aspects of the trip -- none of which are "requirements". Even an available budget of $1,000 is not a "requirement" but a "constraint" on whatever we decide to do.
A web application might begin I want a web site to sell widgets. It is the goal of an Analysis process to collect all of the stake-holder wants -- the benefits that the stake-holders wish to receive from the application -- and discover features that deliver those benefits. Armed with a list of features, a Design process will map sets of features into components that are either on-hand, off-the-shelf, or to-be-built.
It would be easy to take the "sell widgets" want and jump into a full blown e-commerce, shopping cart, inventory, database, thought process. Careful analysis of the collected I want statement might lead instead to a small page count, edit by hand, site that sells a handful of items. Will it grow? Hopefully. The simple site would generate revenue to fund the growth when it happens without sacrifice of today's opportunity.
I'm aware of a project from the days before computer networks. A company had large engineering drawings "downtown" and needed to send them to the factory in the suburbs. They created a plan using messengers and delivery services. The recurring costs were enormous. A janitor was present during one handoff of drawings to the messenger service. He asked "The Boss" if they could take pictures and make those drawings really small. Recalling that the drawings were already stored on micro-film and micro-fiche, "The Boss" agreed. The janitor then suggested that a couple of homing pidgeons could carry the pictures reliably, provide jobs for the keepers, cost a few dollars to acquire and maintain, and they would only lose a couple of birds each year to predators:
I want to send these drawings across town.
Cheers,
~~~ 0;-Dan
Last edited by SaintDanBert; 12-15-2011 at 02:57 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.