I'm about to start building new start-up so i need some guidelines from you.
What's the best way to plan a website? I don't think like "first design, then the database relations, then start development", but "how to plan the way application is going to work"?
Are there some proven methods, like THE best way to do website 'blueprints', like with some tool or something?
I need as much feedback as you people can give me, this is really important to me.
Links, experiences, everything is welcome =)
I'd like some tool to be able to draw the process like
page
- if logged in - do that
- if not logged in - do that 2
Write it down. On a piece of paper. Draw lines between the related parts.
Rinse and repeat as necessarily.
I'm serious. Tools, fancy diagrams, flowcharts, all look pretty for management, but they get in the way of actually understanding how your app is going to work. If it's so complex you can't get it all on a couple sheets of paper, do a big picture view and then do each sub-section.
If you can get a HUGE whiteboard or piece of butcher paper, it's even better. For some reason, having a large space to work on is fantastic for working things out.
I used to do huge specifications in word...hundred pages or more. I no longer believe in that since as soon as you write it down it is likely to change (your ideas, features, etc.). Instead I suggest that you look at an MS product called SketchFlow (which comes with Blend). This allows you to quickly and without writing any code snap together a working wireframe, sitemap, and mock up. While you can create a high fidelity (it functions and looks very close to the real thing) I suggest that you instead focus on creating a low fidelity mock up. There are sketch styles which looks like hand drawn UI elements. This way you can focus purely on how your product works and no so much about how it looks. If there is too much 'finish' put on your mock up you will get hung up on the "big blue button" syndrome where people are more concerned with how a button looks and less concerned with what it does.
I wrote four articles on wireframes, mock ups, and the like and suggest various tools and why I chose SketchFlow. Then I go into building a mock up in SketchFlow.
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Sitemap-and-wireframes-with-Expression-Blend-3-and-SketchFlow-part-1.aspx
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Sitemap-and-wireframes-with-Expression-Blend-3-and-SketchFlow-part-2.aspx
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Sitemap-and-wireframes-with-Expression-Blend-3-and-SketchFlow-part-3.aspx
http://dotnetslackers.com/articles/aspnet/Building-a-StackOverflow-inspired-Knowledge-Exchange-Sitemap-and-wireframes-with-Expression-Blend-3-and-SketchFlow-part-4.aspx
Hope this helps you!
This is a pretty big question. My best advice is to start by thinking hard about your user, what their goals are etc and then draw up some personas. Personas are descriptions of the typical people who will use your site. Once you have your personas you can start to plan your site.
http://en.wikipedia.org/wiki/Personas
Once you have your personas you can work out user journeys - these are essentially flow diagrams detailing how users will achieve the tasks you want to help them with.
http://www.boxesandarrows.com/view/an_introduction_to_user_journeys
From user journeys you can work out the pages you'll need to create in the form of a site map.
http://en.wikipedia.org/wiki/Site_map
Then finally you can work out the content of the pages as wireframes.
http://en.wikipedia.org/wiki/Website_wireframe
There are loads of tools out there: Visio (http://office.microsoft.com/en-us/visio/FX100487861033.aspx) for the PC and Omnigraffle (http://www.omnigroup.com/applications/OmniGraffle/) for the Mac. Both these tools have web design stencils available for free download on the web. There's also a great online tool call Balsamiq (http://www.balsamiq.com/products/mockups) that allows you to lay out pages without having to use a design tool. In the first instance though a pen and paper are the only tools you need.
Once you have these details sorted you can start to think about data models, graphic design etc etc. However this whole process is iterative and you might say will never be finished :)
Good luck!
Develop your data model first. Even if you don't go whole-hog with UML, get a sense of how your data will be represented.
Come up with some use cases to validate your data model. It doesn't have to be perfect, but it should be 99% there to avoid pain in the future.
Once you have a data model and use cases, your interface needs (in your case, your website) will become a great deal clearer. Of course, I'm coming at this from a purely back-end perspective.
Once you have an interface that's workable, hire a good UX specialist to round out the details for you (both workflow and actual interface).
Related
Context: Ok so I am building a website for a friend. Hes a designer with a high need to daily include his projects (images and text).
Problem:
Ok so I know pretty much how to code in html/css/javascript a front end responsive website, that is the easy part for me, the hard one is the content page. I've never done it so I don't know the best way.
A page that he goes daily put a new project, new images, formatted text (A like a blog). But since he doesn't know anything about coding and front end, it has to be simple enough for him to understand.
Resources: I made several searches and found some websites that allow custom templates with content, one of them standing is wordPress (haven't used it for years). I am currently abusing tumblr for that matter, but their support is quite bad. Should I use one, should I buy a host like bluehost and create my self one, what you guys recommend? I tried google it but perhaps I am not doing it the right way since I am not finding any answer to my problem.
Look, you've come to a programming website, so the most common suggestion you'll get here, and the option I myself recommend is:
MAKE IT YOURSELF!
It really is a fun and very educational experience.
There are many, many ways to do this. In general you'll want to have a front end that communicates with a back end API.
For the front end, there are a lot of options. From templating engines like Jekyll, to MVC frameworks like Laravel, to full fledged high level abstractions like Angular and React, which are admitedly harder to learn but so, so robust, and useful once you've figured them out.
The selection of tools you can use to make the API that supports the website is just as rich. There is ASP.NET for C# (which some people use for the front end as well but I wouldn't), there is Node.JS for JavaScript, with a myriad of libraries and packages to get you started. Flask is a popular option for Python. The list goes on and on.
Oh and dont forget about Ruby on Rails.
As for the interface which your friend will use to add their work, turning all that complicated back end into a simple, easy to use interface is a fundamental part of UX design and, IMHO, quite satisfying once you get it right. Make it sleek and, most of all, intuitive. One shouldn't have to be taught how to use it. It should be apparent from the first time they open the page. You should always ask for their feedback as you are developing it. Some even opt to create mock ups of the interface, in order to get feedback on both its aesthetics and its intuitiveness before a single line of code has been written.
Now, regarding how you'll actually do it, the answer really depends on the tools you opt to use. In general, you'll want to read up on things like the MVC pattern, or React's component architecture. The former is something you'll come across on a wide variety of platforms. The latter is mostly React specific, but in my opinion, understanding how to properly build a website using component architecture means you're in the right mindset, something that will help you no matter how you choose to build it.
All that being said...
Web development is complicated. Creating dynamic websites is a much larger undertaking that designing a static page, or even making an SPA. Though I do wholeheartedly recommend you do it at some point, starting with your friend's website might not be the best idea. Or, you may simply not have the time to sift through all your options, figure out which is best for you, begin the learning process etc.
In that case, there are plenty of publishing frameworks and tool sets to choose from. Wordpress has become very popular in the recent years, and templates and plugins for it are abundant. Alternatives like Medium and Ghost have also gained some traction.
There are plenty of commercial CMS type frameworks. One I have heard good things about is ExpressionEngine. However, I cannot speak for it with certainty.
If you are looking for a website builder, there are also plenty of options out there such as Weebly, Wix, as well as Squarespace. Google sites is a relative newcomer in that department, but seems promising.
So, in summary,
I wholeheartedly recommend building it from scratch. There are many, many languages, frameworks, and tools out there you can choose from, each with its own patterns, best practices and idiosyncrasies. If you lack the time, or simply don't feel like going through that process of building a dynamic website from scratch, you can use one of many tools available. However, that wouldn't be nearly as much fun, and would likely produce an inferior result.
I am attempting to learn css attribute relationships. With my current knowledge, I would venture to say that there are only about 30 or so attributes that the majority of web pages are built around, but how you match them up is what gives one page a cleaner look, better functionality, and an overall better experience for the user. Currently I am getting feedback that the 'only' way to learn is by a combination of experience and looking at examples of implementation(s) on webpages that have the feature(s) I want, and trying to replicate. I think this is too time consuming, and not an effective tool for someone wanting to develop a solid approach to CSS. Is/are there tools that you have used similar to any of the below that help you understand the interaction of the attributes for basic manipulation of semantic markup?
Current tools that have GUIs to allow quick feedback of attribute/element manipulation:
JSFIDDLE : An online platform for viewing HTML, JS, CSS, and the result in one window, allowing for common shared code.
Button Maker : Dynamic CSS/HTML generation for a graphical button.
SourceTree : For understanding repository structure for Git,
Mercurial and SVN version control systems.
Eclipse : An IDE with 'desktop' organization of multiple implementations, code, and information panes.
CodingBat : An online console for learning Python or Java by 'snippet' coding and viewing results of different passed parameters.
Codeyear / CodeAcademy : An online IDE to allow for both 'snippet' coding and viewing CSS/HTML/JS/results in several structured learning paths.
Specifically, I would like to learn the relationships of postion based styles, such as fixed, float and such.
For me, the best way to learn: Think up of something you want to make. Make it. Go through the process of finding out what works and what doesn't. Figure out how to fix it. Fix it. Be amazed at how crappy the result is. Repeat.
You won't learn all the little tricks by looking at independent examples. You won't learn much by "looking at" anything. Do it. Once you have a basic grasp of what's going on, make something. Copy something. Time consuming? yes, sure... if you say so. Experience comes with time.
The thing with copying other people is that you don't know the process they went through. Why did they do something a certain way? Is it even right? Just because somebody put it online doesn't mean it's any good.
So specifically, what function do you want to implement? Google that, read all the different ways people do it. Find one that you like, implement it. Tweak it. If you don't understand, look into that.
I think there's a term for when you're trying to find something, you go from one (related) thing to another until you forget your original issue... That's bad when you need to be productive. It's perfectly fine here, where you just want to learn everything.
For some things, it's important to have structure. Once you learn the basics, I think having some sort of structure or system will just slow you down. I like to go at it and solve a problem, learning as I go. When I'm trying to figure something out, I have nothing but Notepad and Chrome with a lot of Google search results tabs open. You don't need all these GUI tools. Sure they might make your development go a little faster with their auto complete or error warnings, but what's your rush?
Don't spend so much time finding the perfect set of tools that you never get to the thing you were finding those tools for. Just do it.
I'm a non-developer building a simple Access 2003 database for an NGO that works in developing countries. I would like to provide in-app help (what certain fields mean, for example) in a number of forms and on the switchboard. I'm not sure about the best way to do this - not just on a technical standpoint but to increase user-friendliness. The users are usually using MS Access for the very fist time, and have only basic computer use knowledge.
I don't want to cram the forms with help text, so I'm thinking of adding little question mark buttons that pop up a separate form with just help text. Is that wise?
I've also noticed a Help Context ID property, but it looks complicated (I'm looking for something as simple as possible to implement, so that the help text can be edited as easily as possible by others in the future). I think this is where I'd start if this were the way to go: http://support.microsoft.com/?kbid=209843
This may need to be translated, etc, so again, the simpler the better.
Thanks!
I've built such a system using tables and forms in the FE. You can get an idea by reviewing some of the screen shots at http://www.granitefleet.com/ScreenShots/index.htm I only created general help describing processes where something on a setup form can affect this form. So the user will know where to ge to change something around.
If you haven't built your forms yet, put that information in the table design, using each field's Description. That will propagate through your forms, and will be displayed on the Status Bar whenever a user click in that field.
If your forms are already done, use the [Status Bar Text] and/or the [ControlTip Text] property of your controls.
Just train your users or write once that they should read the Status bar if they need more explanation.
KISS (keep it simple and simple)
Great question. I think the real solution to reducing the amount of work that you need to do is to work really hard on having a simple, clean UI. In the real world there are very few people who have the patience or inclination to read the manual or search the contextual help even in the face of being stuck.
I know this is slightly off topic from the question but if you look at this website for example it keeps the number of things you can do on anyone 'screen' down to the minimum and everything has a tool tip (ControlTip Text in msaccess). Even if site this was in Japanese, I thin i could navigate around it fairly easily and that is because of its simplicity. (I couldn't answer any questions though :P)
Jakob Neilsen has a great site on usability
" I think the real solution to reducing the amount of work that you need to do is to work really hard on having a simple, clean UI. In the
real world there are very few people who have the patience or
inclination to read the man*emphasized text*ual or search the
contextual help even in the face of being stuck.*
Regarding this, it really depends on the application. It is overly simplistic to assume that every application can have all the information it needs to be operated just by having a simple clean UI, especially if in the name of being simple, there are alot of useful features that are not included. In certain complex applications, people will simply need to have patience and read the information available or they will waste a lot of time guessing. It is better to have have information at the press of a button than have them asking for it once they figured out that they are wasting time figuring it out with no help. I agree that many apps are way more complicated than they need to be.
I have a horrible habit, actually something I'm wrestling with right this moment, when I think of a better way to do something - either a refactor, or something that would just be SO MUCH COOLER LOOKING, or such a better UX, I just HAVE to do it. Even when it would cost me time and I'm in a time crunch. I never know when to say, "no, there isn't time for this I can do it later."
Is there a line you draw?
Like right now I need a way to display magazine articles that are in the database. The easy way would be to create a new .aspx page and just pass the article id. the AWESOME way would be a jquery fade in modal that would display the article. At least that's what I think. Not being a guru it would take me longer to write. We are launching next week no time for extra crap. However, I just can't bring myself to do it the easy way.
Does anyone else run into this problem? Wondering if more experienced programmers have some wisdom to share.
I'd go the quick route first.
Write an ASPX page that is showing an article based on ID, or even cooler and more SEO-friendly, a slug. You'll be able to meet your deadline. Then, I'd start on the awesome jQuery way.
The bonus to this is that you'll have a fallback option, in case that a user has JavaScript disabled.
You're talking about "gold plating". It's a very common and well-known issue for software developers.
From the glorious founder of StackOverflow himself:
30: Developer gold-plating. Developers are fascinated by new
technology and are sometimes anxious
to try out new features of their
language or environment or to create
their own implementation of a slick
feature they saw in another
product--whether or not it's required
in their product. The effort required
to design, implement, test, document,
and support features that are not
required lengthens the schedule.
The proper way to cure this problem is to volunteer for so much work that you don't have time to do it right, let alone add on extra bells and whistles. :)
Edit: Other "classic mistakes" link here.
I think it's just a matter of setting priorities. Also, if your client, or boss doesn't want you to do things the flashy way, and you don't really have time to do it the flashy way, just do it the simple way, and come back and upgrade to flashy if you have time later. Clients and bosses are usually happier when you finish the work they gave you before moving on to making things better.
I look at how much time I have left, and if I feel I am pressed, I don't venture outside of my area of expertise. I am all for doing it correctly and elegantly, but the reality is that the majority of the time the deadline takes precedence, and I know if I stay within my comfortzone when pressed, I will most likely make fewer errors which means I save the QA people time in testing things.
That all being said, I have been known on more than one occasion to push the limits of how much can be done. If you aren't working an immense amount of overtime already, you can always make extra the time necessary for going the harder route. Yeah doing this can cause a little more work for extra people but sometimes that's the difference between having the best application or having the first loser.
My other advice is don't try and do both options. If you create a basic version stick with it and move on. If you try and do both, you're really wasting time in the end.
The right way is to have it functioning so that users can get to the information they seek. The designer way is to have it kind of working but also have javascript light things up and move around.
The best way is to get it working correctly then revise it. There shouldn't be much refactoring involved if you know where to place things. Obviously retrieving the article is going to be business/app logic and the actual fancy design (like fades/animation) will be part of the design/view aspect of the setup. These portions should be able to sit and be somewhat ignorant of what the other is doing - they shouldn't be tightly coupled.
Sounds like typical feature creep. Convince yourself that tabling a feature idea now to meet a deadline is quite different from simply dropping the feature altogether. You can come back to it months after release and put in new features.
I think you've pretty much answered your own question there. You said that adding this feature would take too much time, and you're in a time crunch and are launching next week. I think it's fairly obvious you need to go the "easy" route.
You're basically describing feature creep. http://en.wikipedia.org/wiki/Featuritis
You need to discipline yourself, what I would do in your position is document the new feature I want to add, and implement it after your out of crunch mode when you have time to work on it. You're obviously aware that adding this feature is going to cost you time and may very well set back the launch of this product, you just need to have the discipline to prioritize and stick with it.
I think every developer has this problem if he is interested in programming and isn't coding just as a way to make money in a 9 to 5 office job.
Here is my advice:
Make a list of every cool thing you think of as you're writing the code. After you have a working basic version, commit it to your source repository.
Now if you have time left go back and do as many cool things as you have time for. Use branch tags if you're going to have to seriously rework the code.
Once you run out of time, if you're doing Agile, write the leftovers up as stories and give them to your project manager or client.
I think when you say you are doing something the "right way" that implies a balance of quality with the speed you can write it in.
If you make something as high quality as possible, but never release it, it's not the "right way". On the other hand, if you write crap but get it out super fast, that's also not the "right way." To do something the "right way", you must balance these two.
An economic phrase that comes to mind is "Quality, Price, or Production Speed, pick two."
Things like this used to absolutely kill me!
Here's my advice:
Do it the easy way (the aspx with the
id parameter)
Write a small proof of
concept to show the client
Show the client the working page and the proof of concept later along with an estimate on how long it will take. The experience of designing the prototype will give you a better idea of what is involved, how to do it, and how long it will really take. The proof of concept can also inform maintainence developers what's what (fading vs logic), and allow them to issolate if the fading mechanism or logic is broken.
Personally, I would stay away from the fading thing. In my experience the client will see no added value in the fading functionality and IMHO seperating it to another page will be easier to maintain. I believe it will be less prone to bugs later since code for the 2 pages will not be intermixed onto one page (if I understood you correctly).
In test driven development approach, when you implement a feature by writing a test for it and implementing it the easiest possible way, you will be able to go back and do it "right" only when you find really need to do so. Knowing this allows you to avoid overdesign. And often, you find you won't need to after all.
While designing my site I am constantly faced with the issue of whether its ok to TAKE ideas and designs from other sites. In some cases there is no distinction in certain aspects. Is there anything ethically wrong with this? Is this expected in the design programming community?
Depends on how much you 'steal'.
Code
If you're ripping off the whole design, then its a bit dodgy. If you like (for example) the Stack Overflow concept of voting up stuff, then steal the concept and use it in a different manner. If you want to know how say the orange highlighting of the up-voted items works, then look at the code. But don't do both and steal both the concept and the design, you'll just create a clone.
Due to the way different web browsers treat CSS and the like, there are often only a very few limited ways to do a particular thing (3-column layouts, etc.). It seems fair enough to blatantly copy in these cases where there is a common way of doing things. Where its something unique, and there's many ways of doing it, it seems a bit more off to blatantly copy.
Graphics
Ripping off graphics - not so okay. Images have been around a lot longer than code so copyright law, etc. probably suits them better. If nothing else you have to contend with possible watermarks or other metadata to identify the original source. It's very easy to check for image stealing, less so for code within a larger block.
I'm a coder, not a designer so what I tend to do is borrow graphics that I like just while mocking up my web-app for internal use. Does that seem fair? I'll change them for newly-designed or paid-for ones before going live. At least that's the idea, though it could be far too easy to forget and use them by accident.
That's the way it works in the newspaper world (well it used to, not sure now with the advent of this there Internet thang): You download as many graphics as you can bother waiting to come over your 57.6k modem; you only pay for the ones you actually publish.
Oh, this is a hard question.
On the one hand stealing is wrong, on the other hand you are obliged to save you employer money by solving a task quickly.
My only advice is:
If it feels wrong in your gut, you probably stole too much.
I think most designers and developers draw a distinction between 'creative inspiration' derived from someone else's work and blatant plagiarism.
I wouldn't think twice about peeking under the hood to see how someone had done a particularly nifty javascript effect, or implemented a tricky piece of css elegantly, but I'd find it distasteful to blatantly cut and paste that same code for use in my own development.
I'm not learning anything by just grabbing and reusing - although I think it's fairly standard to have the same code to hand as a rough scaffold from which to explore my own way of implementation. I think that's the way a lot of people work.
I am a web developer, not a designer. As such, I have a sense of taste, but not the ability to come up with something wholly on my own. As a matter of ethics, everything commercial or with the expectation of serious traffic that I do, I will hire a designer. They need to eat too, and there is something wrong with making money off of others work and not compensating them for it.
If it is small, personal, or an internal throwaway type thing, I will rip off things like color scheme and/or layout. Technically you could say this is stealing, but I think of it more as "imitation being the sincerest form of flattery" thing. I don't feel that bad about it since there isn't really any money to be made in it.
I think its ok to steal ideas, but not to steal code.
This is how a lot of design is accomplished. Except it's obscured by lots of lifts, not a single wholesale lift.
Stealing resources (graphics, code) is not really OK if they're not specifically marked as free/open/creative-commons/etc. Stealing design and layout is a bit sketchy if you're just xeroxing the same layout using your own code -- using someone else's design as a starting point is one thing, but don't just recreate their design verbatim. Stealing snippets of code for specific bits of functionality is fine (IMHO) since even if you grabbed a reference manual to learn it from scratch you'd end up with the same thing. (Think: javascript for changing an button image on mouse-hover)
Having said all that, imitation is the sincerest form of flattery. Don't steal resources, but using other sites as "influence" should be OK. Or, if in doubt, ask the owner of the site you intend to use as reference/influence.
It's almost like everyone answering this question forgot what it was like to work with web pages between 1995 and 2002 or so. Stealing was a way of life for tons of designers during that period. The key was, and still is, to take only what you need, and to make sure that you understand it well enough to make it from scratch the next time. Who knows, you might improve something in the process.
There's an old saying I was once told: Good designers create. Great designers steal.
That said however, you should never blatantly rip off code if you can avoid it. Look at it, understand it, rewrite it (or improve it, if possible; even if it's only something like using what you find are better variable names) but never just copy and paste. Same goes for layouts; take the layout and modify it to suit your needs - it might end up looking similar (look at all of the Basecamp-style clones out there as far as UI goes) and that's no big deal at all; plenty of sites look similar. The key is to go into the situation looking for inspiration and not some code to yoink. If you can use the code as-is or with little modification then you really have no problems, but it shouldn't be your intention to find someone else's code and rip it off.
It's a sliding scale. Borrowing just an idea is one thing, if you're incorporating it into the rest of your existing design, not just wholesale copying an idea. Snagging a idea for a design element is fine, copying a whole design exactly is not. As you borrow more and more of a design, it gets into the not acceptable category. Copying directly is also another factor. If you see something you like and reimplement it for yourself, that is typically fine. But doing a direct copy of code, images, or css not so much.
For the most part, ideas are fine to take and implement. If people couldn't take existing ideas and expand them or re-implement them, we'd never have gotten out of the dark ages.
If you feel the need to steal code because you can't code HTML/CSS well or don't have an eye for design, steal from a place that explicitly permits you to use their design/code, like OSWD. In general, stealing HTML is fine, but ripping off CSS wholesale is a no-no. Just because you can easily view the CSS source doesn't mean that it's ok to just copy and paste it.
Don't steal graphics, period. Especially things like photos and logos and icons. If you need that sort of thing, purchase stock photography or take your own photos.
When in doubt, ask the owner of the site.
Stealing code or designs is immoral and in some cases illegal.
Taking inspiration or copying functionality is less of a problem. For example, at some point in time someone realized that putting a "Forgot Password?" link next to all login forms is a good idea, now everyone does it. It's not theft it's just replicating a good idea.
I'm not a web developer, but I might have some insight that will help as well. My team has created several applications that have served as the starting point for other applications delivered to various customers.
The successful derivatives were those in which the developers took the time to learn the architecture and why things were the way they were. They then took the more crusty parts and rewrote them and in general expanded and improved the architecture.
Invariably, when a team simply took the existing project and tried to 'brand it' or copy it for a customer without actually figuring out the systems, they either created poor implementations of the extensions or had the project fail outright.
I realize this is a bit off the main topic of the ethical issues address by others here just fine, but my bottom line is that pure theft usually costs you more time than it saves.