I am an extremely beginner level web-designer. Recently I was hired in a company to create a domain from scratch. They requested their domain to be bilingual. I do not know any JavaScript, so I came up with the idea of creating two separate html files in which I translate the content to the required language and then just make a ref link so when the user clicks on the en.icon the English html page pops up.
Is this solution functional, will it cost them more money when hosting their website? does it affect loading times significantly?
If no what are possible solutions I can proceed with.
Well, it would be very ineffective for you to write a different html page for each language. If the project is small and won't expand in the future it should do the trick but it definitely isn't the smart way. Imagine having a 1000 page website.
I would suggest that you learnt a bit of Javascript and change the text in the current element depending on what the current language is.
You can store the current language in a cookie or in the localStorage/sessionStorage (the second option is really simple).
It will help you a lot if you look up basic DOM (HTML Tree) manipulation in Javascript. Do not worry if you don't grasp everything from the beginning. Everyone has went through that. It is simple and it shouldn't take you that much time. Take your time with javascript and it will pay off in a few months.
After you've got the basics using vanilla Javascript you can try ot jQuery. It will simplify things a lot but I recommend learning things the hard way so that you have a deeper understanding of how things work.
Whether or not you want to become a developer or you just want to be a designer, learning the basics of programming will be of much use.
I hope I was helpful. Good luck with the website!
Related
I'm coding a basic game in HTML/javascript/CSS and I'm just after some advice on best practice/best way to do it.
I only have a basic knowledge of javascript but it seems easy enough and there's nothing too fancy required in my game.
The game will be relatively simple in that it's mainly menu/screen based; there will be a main menu which the user navigates from, which will open the required screen for them to make in game purchases etc, before returning to the main menu screen.
What I'm trying to work out is whether I should do it as just one page, that dynamically changes as the user makes their choices, or several pages for each of the menu items. The second sounds much 'cleaner' in terms of code and layout, but then I have to pass variables across to each page. Some of this information needs to be secure, so I'm thinking of using HTML5's localStorage or sessionStorage. It seems to work well in Chrome but IE8 doesn't seem to like it during my offline testing, apparently you need to have the file uploaded as it's 'domain' based? I thought the whole 'local' meant it could be done locally!
What I also need to consider is that in the future I'd like to convert this to a Facebook or even mobile app. I believe there are some 'wrappers' available and that you can port it across... is the fact that I'm planning on using multiple pages/localStorage going to affect future portability? Is there another way I should be doing this?
Thanks
I have create a few HTML5 Javascript games, I for one did not purchase any books as you can usually find some good stuff out there on the web, so just do some google searchs for HTML5 canvas game or Javascript Html Game.
The best thing to try and keep in mind is OOP (Object-oriented programming), this really helped me out create my simple games as it just keeps a nice pattern.
But basically what I did was just dive straight in and just code. A good editor is Sublime.
Sorry I couldn't off been much help however, if you take a look at a game I created and view the source files, you may get a good understanding of how to create a game :)
http://canvascode.co.uk/Projects/SpaceDestroyer/spacedestroyer.html
Also you could always pick up Unity which is portable for nearly every system there is :)
I have learned and can read/write code in JavaScript. I am a backend engineer by profession and want to learn how to build websites. I have gone to the point where I can build wireframes and start writing basic HTML. I've never succeeded in creating a complete webpage, because they always looked awful midway through.
I've seen many JavaScript frameworks (like Bootstrap, Backbone.js, and others) that one can use to create websites.
Which framework(s), if any, should I use? Which would you recommend I use to start building websites (and why, if applicable)?
I wouldn't recommend you using a JavaScript-framework to build your entire website. I would only recommend JavaScript to enhance your website with cool features.
I'm not sure what type of website we're talking about, but if you're planning on getting traffic from search engines — think twice.
Google aren't that good at reading content embedded in JavaScript. Meaning: your SEO will be terrible if you choose to build the website entirely in JavaScript.
HTML/CSS is easy, man. I'm sure you'll be able to learn that in a one day — tops! You're a backend engineer by profession for gods sake, HTML can't possibly be that hard to get a grasp of :)
I was in your exact shoes not so long ago - I'm a programmer and had no issues picking up the backend programming that is required of websites, but when designing the web page is something I just could not do. I would end up with terrible looking web pages which was very discouraging.
One great way to get around this is use HTML/CSS templates - there are plenty free ones available. Download one you like, then go through the CSS and change as much of it as you need to personalise your site. This process will also give you a great understanding of how CSS works, and how it should be used to design a page.
After doing this a couple of times, you will be confident/able enough to design a webpage from scratch. If not, continue using the templates. No harm in that.
As others have already mentioned, for a powerful, dynamic website you will need a server side language as well. Javascript frameworks like jQuery are nice for the front-end for the website. For the back-end you can try CakePHP, CodeIgniter etc., or just code the back-end from scratch. Doesn't seem that would be a problem for you.
Some sites that provide free HTML/CSS templates:
CSS Creme
FreeTemplatesOnline
Most of them are optimized for 1024x768 which might seem a little outdated for a few. Try tweaking the CSS code to make the template suitable for your purposes - change images, width etc.
You can't exactly build a website using JavaScript. You could, but that would be very inefficient...I recommend going through some HTML tutorials, as you (and the websites you build in the future) will benefit a lot from the fact that you use HTML primarily, and enhance it with JavaScript. After all, JavaScript can't do much in comparison to HTML (since in order to build a site with JavaScript (or my interpretation of what that is), you need to have a basic understanding of HTML).
Unless I misunderstood your question, then that's about it. Frameworks like jQuery can really enhance a page and make it beautiful and, fortunately, much more user-friendly.
You can't create a website (at least a dynamic one) without a server side language. There you can pull from a number of languages.
If you are just a JavaScript fan, then you can use server-side JavaScript code as Node.js. On the client side you can use jQuery and you can have a supporting database like MySQL.
I'm new on this whole web design business, and I am beginning to think I am going against good practices, so I had some questions.
I am making a website for a family company. We have a great deal of products that often change, and I need to make the site in a way that it will be editable by someone else less tech savy when I leave the company. My plan was to keep each product in an xml file loaded via javascript on each page. Later, I might attempt to write another script to make editing these xml files easy.
I am worried about two things. First, I am getting a sense that this is bad practice because some users disable javascript. Second, I am worried that search engines will not be able to find content on my site because all they will see is some template html and some javascript. I would like to be searchable and use good practice, but I have no idea how to solve the issue of dynamically changing content that is easy to edit in another way.
I would really appreciate if someone would point me in the right direction so that I know what I should be researching.
Thanks
RShom
There are many good free, open-source software products that let you create a customizable content management system (CMS). Drupal and Joomla are very popular ones.
Try searching for "free cms" and see what you find.
I bet you must have heard of PHP, even if you are not using it. I suggest you use PHP to parse your XML into HTML and present. Then your content will be searchable because PHP is server-side scripting. You are going to be using javascript, too, but it shouldn't be for the XML. It is to me for enhancement of a webpage (aside AJAX).
The previous programmer left the website in pretty unusable state, and I am having difficulty modifying anything. I am new to web design so I don't know whether my skills are a mismatch to this kind of job or is it normal in the real industry to have websites like these
The Home page includes three frames
Each of these frames have their own javascript functions ( between <head>, and also call other common javascript functions (using <script src=..>
Excessive usage of document.all - in fact the elements are referred or accessed by document.all only.
Excessive usage of XSLT and Web Services - Though I know that using Web Services is generally considered a good design choice - is there any other way I can consume these services other than using xslt. For example, the menu is created using the data returned by a web method.
Every <div>, <td> and every other element has an id, and these id's are manipulated by the javascript functions, and then some appropriate web service and the xslt files are loaded based on these..
From the security perspective, he used T-SQL's for xml auto for most of the data that is returned by the web service - is it a good choice from the security standpoint to expose the table names and column names to the end user??
I am a lot confused about the state of the application itself. Should I learn about the intricacies that he has developed and continue working on it, or should I start rewriting everything? What I am perplexed a lot is the lack of alternatives - and whether this is the common way web projects are handled in the real world or was it an exception?
Any suggestions, any pointers are welcome. Thanks
No, it is not acceptable in this industry that people keep writing un-maintainable code.
My advice to you is to go up the chain and convince everyone that this needs to be rewritten. If they question you, find an external consultant with relevant web development skills to review the application (for 1 day).
Keeping this website as-is, because it 'works' is like keeping a working model Ford-T car on today's highways, very dangerous. Security and maintenance costs are likely the most persuading topics to convince anyone against keeping this site 'as-is'.
Next, get yourself trained, it will pay off if you can rewrite this application knowing the basics. Todays technology (asp.net MVC) allows you to implement core business value faster than trying to maintain this unconventionally written app.
Tough spot for an inexperienced developer (or any) to be left in. I think you have a few hard weeks a head of you where you really need to read up on the technologies involved to get a better understanding of them and what is best practice. You will also need to really dig down into the existing code to understand how it all hangs together.
When you done all that you really need to think about your options. Usually re-writing something from scratch (especially if it actually works) is a bad idea. This obviously depend on the size of the project, for a smaller projects with only a couple of thousand lines of code it might be OK. When looking at someone elses code it is also easy to overlook that all that weird shit going on could actually be fixes for valid requirements. Things often start out looking neat, but then the real words comes visiting.
You will need to present the business with time estimates for re-writing to see if that is an option at all, but I'm guessing you will need to accept the way things are and do your best with what you have. Maybe you could gradually improves things.
I would recommend moving the project to MVC3 and rewriting the XSLT portions to function using views and/or partial views with MVC. The Razor model binding syntax is very clean and should be able to quickly cleave out the dirty XSLT code and be left with just the model properties you would need.
I would then have those web services invoked from MVC serverside and for you to deserialize the object results into real objects (or even just use straight XQuery or Json traversing to directly pull stuff out for your model) and bind those to your views.
This could be a rather gargantuan leap for technology at your company though. Some places have aversion to change.
I'd guess this was written 6-7 years ago, and hacked on since then. Every project accumulates a certain amount of bubble gum and duct tape. Sounds like this one's got it bad. I suggest breaking this up into bite size chunks. I assume that the site is actually working right now? So you don't want to break anything, the "business" often thinks "it was working just fine when the last guy was here."
Get a feel for your biggest pain points for maintaining the project, and what you'll get the biggest wins from fixing. a rewrite is great, if you have the time and support. But if it's a complex site, there's a lot to be said for a mature application. Mature in the sense that it fulfills the business needs, not that it's good code.
Also, working on small parts will get you better acquainted with the project and the business needs, so when you start the rewrite you'll have a better perspective.
Ok this is a bit of a rant and a question combined - Why the hell is magento so reliant on javascript?? This goes agaisnt all usability guidelines. WHats so annoying is that it even uses buttons instead of correct form submit elements. Why? This makes no sense what sense at all to me.
Why is this and is there a way around it?
The past five years have seen an increase of web application developers eschewing the common wisdom of of the late 20th and early 21st century by creating applications and require javascript as a baseline technology. Magento is following this trend because they want to provide a moden, AJAX enabled experience, and providing both a Javascript and non-Javascript experience increases both development and testing time.
Most decisions in the e-commerce industry come down to the ROI of increased sales. Magento has calculated/bet/decided that sales lost due to people having Javascript off are less than the cost of developing both a javascript and non-javascript experience.
As for their use of the HTML button attribute, Magento isn't a web page, it's a web application. Their architecture takes a Java like approach, including a UI that's abstracted away from the browser. This means PHP is used to tame the browser rather than using PHP to work with the browser. In this context button elements (driven by Javascript) make more sense. Take a look at Google Web Tools for another example of this.
The way to "get around" this is to not use Magento, or to customize Magento such that it fits your model of what web development should be. If your first response to this is "woah, that would take way too much time", then congratulations, you're thinking exactly the same way that Magento is. Magento, the company, isn't Microsoft, or Oracle, or SAP. They're a 200 person company, and expecting them to solve all your problems (for free) isn't realistic.
Welcome to 2010.
Magento's JS reliance is unusable in exactly one way: you cannot use the store without it. That's a big one (losing 1/20 of your customers is not a small thing), but ultimately it's a tradeoff that they decided was worth it.
As an example of the flexibility that you get as a result of this decision, consider the case of configurable products, especially with pricing differences. Magento allows you to create products that are configurable over N axes, in a ragged manner (some color/size combinations of clothing can be missing, for example), with different pricing for every single option. Doing that without JS would be tough, doing it elegantly (which Magento has, for the most part), is nigh impossible. By enforcing JS, the developers at Magento, Inc can spend their time implementing these kinds of features more quickly, which is to everyone's benefit.
To answer the question at the end of your post, no you cannot get by without it -- at least without writing a new frontend theme that reimplements everything from scratch, which nobody so far seems to have been able to do. Personally, the number of JS libraries that Magento uses seems pretty heinous to me, but nobody seems to have solved that problem either. The app is too complex and tightly woven to unwind that far.
Sorry it's not better news, but I hope that at least clarifies some of the thinking for the way things are.
Thanks,
Joe
"Why is this and is there a way around it?"
Although the front end uses Javascript heavily it is only essential in a couple of places. Configurable products is one. The one-page checkout is another but that at least can be disabled in System > Configuration > Checkout > Checkout Options.
Buttons with event handlers can be rewritten as a matter of theming, in some cases their destination URL is not the same as their form submission so a little forethought is required. In some cases buttons are not in the form element they are submitting, that is why they use script.
I will assume when considering accessibility you are not concerned about luxuries like image zoom and search suggestions. I notice HTML5 provides the datalist element for input suggestions but some sort of script would still be needed to update it beyond the initial suggestion.
Overall Magento is quite functional without Javascript, just not as out-of-the-box. An 'accessible' theme would make a valid extension should someone want to develop it.
We've just been looking into this when I came across this post (first time we've used the magento platform and our first project with it).
Typically we'd ensure that every site we develop degrades gracefully without javascript, but this is looking like it might be too much work for us on this particular project at least for the first phase (tight deadline alongside steep learning curve).
While I agree that javascript can offer some great usability enhancements, providing a non-javascript fallback isn't just about supporting the odd akward person who insists on turning it off.
Some users using disabled access devices (screen readers etc) as far as I know, might not have the option to use javascript either (or may find javascript interfaces more troublesome to use if not impossible in some cases). In these cases if it doesn't degrade gracefully for them, then I'm a bit concerned that it may conflict with disability discrimination legislation in the UK/EU (where our client operates).
For this reason, I'm not sure we can take the position the magento developers have in the long run (we'll probably end up backtracking and resolving this ourselves ultimately and I'm guessing that will take us longer than if it degraded gracefully from the start and we could simply build upon that).
The admin area is less of an issue, but the front end should work without javascript imho and I was a bit surprised when I discovered that it didn't work without it (the client came to us specifying magento so there isn't much we can do but run with it at the moment).
I think you'll find that the Javascript in most cases significantly enhances the usability. Trying to implement something like the Manage Products grid, Manage Categories tree or Promotions editor without Javascript would be a usability nightmare. When you look at the stats, well over 95% of browsers have Javascript enabled, so what's the problem?
Try using this site with java-script disabled. It works but start counting the post backs and you will see why usability trumps the few folks who insist on disabling java-script.