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.
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'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).
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.
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.
What are the pros and cons of using a WYSIWYG editor for web page development vs hand coding?
With the exception of just not knowing how to create something by hand coding is there any reasons to use WYSIWYG?
I handcode, but I prefer to work with a wysiwyg editor in tow, and for that reason I'm still using Dreamweaver as an editor. What I'm doing 95% of the time is handcoding inside the Source editor and viewing the results in the preview. Occasionally I'll drop into the wysiwyg editor to move blocks around directly though and when I do I find it invaluable. I never use any of Dreamweavers wizards or generated code and I clean up the html manually too.
I see nothing wrong with this approach, it strikes me as the HTML design equivalent of an IDE prompting to complete functions etc. (intellisense or whatever your IDE may call it)
I also always use a templating system of one form or another so my scripting code is totally separate from html.
The combination with Dreamweaver of the occasional wysiwyg edit (invaluable I find when laying things out or making 'macro' layout changes) and the one click preview has kept me with it despite looking at better tools - Aptana, NetBeans etc. Indeed I would dearly like to move to another system - see this question - preferably something that runs on Ubuntu and strips out the crud in Dreamweaver leaving just the wysiwyg features and possibly an intelligent Javascript editor, but I'm yet to find anything. KompoZer is starting to look promising though.
There are a variety of reasons to use a WYSIWYG editor when creating HTML.
Allows for quick prototyping
Allows designer-y people to be actively involved in front end development
Some WYSIWYG tools will set you up with a clean base to be modified (Dreamweaver's CSS layouts are actually pretty good)
I think the important thing to remember is that after you get it into approximate shape, you should dig into the code and make sure there's nothing weird going on. Nested spans, odd absolute positioning, and (lord almighty) table based layouts count as weird things. Even if you use a WYSIWYG to start with, you should always check that the code is valid and looks the way you would expect it to.
WYSIWYG can be handy if you don't know HTML or just want to whip something together extremely fast. You're not going to get clean code, though. Most WSYIWIG editors still throw out a bunch of unneeded dirty HTML instead of clean solid markup.
Anyone familiar with HTML can usually whip up something just as fast by hand in an HTML editor. And it will be clean, xhtml compliant semantic markup instead of thrown together templates with extraneous crud.
If you set up the template and css properly, you can probably be faster with hand coding than a WSYIWYG editor, as those work against you when you're trying to create properly abstracted css with degradable semantic markup.
If the design isn't terribly important and you're just throwing a website together there's nothing wrong with using a WYSIWYG. Or if you're trying to create a marginally functional mock up for a client it's a good way to get something built quickly.
I develop in ASP.net most of the time, so I'm in VS2008 most of the time; however whenever possible (which is most of the time) I still-hand code....but I do it in VS2008's source mode. When working with ASP.net, theres always somewhat bloated code which you just sort of have to accept (to a point).
However, in my free time, I also do php development, and like hell will I ever not hand-code with php. Plus, its not like VS with the drag and drop stuff.
If you want to be really good at what you do, as in Guru like good, drop the WYSIWYG stuff and start hand coding. The learning curve is steeper, but it makes you better at what you do in a meaningful way.
It comes down to maintainability and changeability. It is usually much easier to change a GUI layout in a GUI editor than by hand.
"Oh you want to move that JTable from this position to this other completely unrelated position". If you have handcoded it, it basically turns out to be a programming job (which for non-trivial layouts might actually be HARD), but if it is in a good GUI editor, it is probably just a matter of point-click-move-release.
People who handcode probably never have had to do that kind of changes :)
The advantages of using a WYSIWYG editor for web development are pretty obvious. Development is much simpler and faster even if you know how to code web since web development requires to know many different languages and can get messy when trying to get them to work together as planned. Real WYSIWYG designers should be able to solve those complexities by allowing you to visually develop on one form in one layer.
The disadvantages of this kind of development paradigms can be that it sometimes limits you, meaning that you are usually constrained within a predefined framework.
Therefore it is important to find a framework that on top of its WYSIWYG development experience is open to extension and customization. Take a look at http://www.visualwebgui.com/.
This is the same type of thing as Glade versus hand coding your Gtk code. I think that you add a level of obfuscation and things that might break when you hand edit your code. However, as Spencer said, if you need to do it and it needs to work; usualy WYSI wil work pretty well and reliably. If you're doing something that you're going to be keeping up to date and be managing for years to come; you should know every piece of code that is in that application/web page.
Really it comes down to your job function. If you're primarily a designer, WYSIWYG editors can be very handy for creating mock-ups for clients, or prototypes that can be handed to developers to code against.
If you're a developer, you'll probably prefer to hand-code.
Most WYSIWYG editors offer a code view and design view which enables you to switch back and forth pretty easily.
My suggestion is to try and learn how to hand-code your site. After years of web development, I find that hand-coding is faster for me than attempting to use a designer. Moreover, as you gain a better understanding of how HTML and CSS work together you'll find that there's very little that can't be done gracefully.
It can be frustrating to learn, but you'll find that you're better for it in the long run.