WHERE WAS THIS THREE MONTHS AGO!???
After all the headache JavaScript has presented throughout the semester, I was almost shocked to see that all I've learned to do with JavaScript, which I'll admit isn't much, can be done within about ten minutes with the Spry Framework. I spent hours trying to get the code to work as it should and usually end up finding small typographical errors or other elements that are missing or incorrectly written.
In my short browse of what I've included in my Spry Framework page (quite literally thrown together), I can see some of the same elements which were used throughout the course. I notice there is a style for overflow: set to hidden in the CSS for the accordion style. Much of the other elements Spry includes are just for better looks on the page. I would definitely spend more time updating the styles to match the page if I had more time to do so. The JavaScript included with the Spry Framework uses many familiar commands. The latest in my curiosity with the script are Regular Expressions for searching data which can also be used for validating forms. I noticed they use that with Spry for searching out their classnames and applying styles.
I hope to learn how to use this with better efficiency in time, but for now, I'm probably going to focus more on server-sided coding for websites and use the client-side scripting for small things that make the page look cool without ruining the accessibility.
Monday, December 14, 2009
Wednesday, December 2, 2009
Farewell
As the semester comes to a close, I look back at what I have and have not been able to do and wonder where the future will take me. Much of what I have learned has been review of what I'd seen but not understood previously. The syntax and layout of JavaScript has been similarly prominent in other scripts for projects this semester, such as action scripting in my Multimedia Authoring course with Adobe Flash. An interesting point was made by the author of the JavaScript course book when he referred Robert Penner's site for movement mathematics and commented, "He created the movement calculations for the Flash environment, so I'm pretty sure he knows his stuff."
Using the scripting languages has begun to develop my learning center, but the real meat of scripting has not yet found a place in a busy schedule. Most of the time I need a good three or more hours to test and try and work through the material. Anything less than that seems to be too little to even start wrapping my head around it. It doesn't seem very hard to understand the programming concepts that were so aptly acquired last semester, but to produce the concepts and do it error-free is a challenge for a future day.
Throughout the progress of this course I have had challenges with basics which throws a real sting in anything complex. Searching out the basics would have solved many problems quite early on, but due to the extensive scripting code being more foreign to me than the raw HTML or CSS, I was more prone to search it for errors, often finding it was a basic syntax or logical error in my HTML. Noted well was a suggestion to validate the code when trying to find errors (Ryan gets credit here).
My passions have come and gone for some things, but I can generally spend a lot of time scripting or programming or coding in languages I've come to understand and master. It genereally happens in the quiet of the night when everything else takes a back burner. A few all-nighters generally produces a project completion or probing unbeatable confusion (like not closing anchor tags .... validate!) until a light comes on in a clear mind. I hope the passion for overall web development grows as I learn and understand concepts in ASP.NET and develop sites for real-world use. I get most of my satisfaction in life from discovering ways to use the tools of technology to improve and convenience life for people.
Will it stop here? Not likely.
Where will it end? In the degradation of JavaScript and advancement of more powerful tools for development.
Farewell is only a word to depart from the present. The future (motivation included) looks bright.
Using the scripting languages has begun to develop my learning center, but the real meat of scripting has not yet found a place in a busy schedule. Most of the time I need a good three or more hours to test and try and work through the material. Anything less than that seems to be too little to even start wrapping my head around it. It doesn't seem very hard to understand the programming concepts that were so aptly acquired last semester, but to produce the concepts and do it error-free is a challenge for a future day.
Throughout the progress of this course I have had challenges with basics which throws a real sting in anything complex. Searching out the basics would have solved many problems quite early on, but due to the extensive scripting code being more foreign to me than the raw HTML or CSS, I was more prone to search it for errors, often finding it was a basic syntax or logical error in my HTML. Noted well was a suggestion to validate the code when trying to find errors (Ryan gets credit here).
My passions have come and gone for some things, but I can generally spend a lot of time scripting or programming or coding in languages I've come to understand and master. It genereally happens in the quiet of the night when everything else takes a back burner. A few all-nighters generally produces a project completion or probing unbeatable confusion (like not closing anchor tags .... validate!) until a light comes on in a clear mind. I hope the passion for overall web development grows as I learn and understand concepts in ASP.NET and develop sites for real-world use. I get most of my satisfaction in life from discovering ways to use the tools of technology to improve and convenience life for people.
Will it stop here? Not likely.
Where will it end? In the degradation of JavaScript and advancement of more powerful tools for development.
Farewell is only a word to depart from the present. The future (motivation included) looks bright.
Monday, November 23, 2009
Events
Events in JavaScript are still very shady to me. I see the way they work, and I only slightly understand the way browsers execute them. A great deal of this chapter on events covered cross-browser problems (especially involving Internet Explorer) and was confusing in explaining the core details of event listeners. I can't firmly say I understand them. In order to troubleshoot those I have been able to implement, I have taken the code archive and stepped through each action to see where the next part of the script would be executed. It's been quite a rollercoaster ride through spelling mistakes and logical errors on my part, but it's helped me see how some parts work. It takes a lot of work to get the functionality as intended when working with an already-existing page, but the efforts seem to play out in the end. I can see the importance of being able to use events now, and I hope I can implement the idea in further projects throughout my expanding web development hobby or career.
Events are important to the extent of user interaction on a web page. It is important to let users be able to interact with a page for a better user experience while visiting. At the same time, however, just as with design and form, the function or behavior of the page must be separated from the content of the page. In this way we keep accessibility alive and our code can be reused in other cases for the same processes in the future that we need on particular pages we create now.
Events are important to the extent of user interaction on a web page. It is important to let users be able to interact with a page for a better user experience while visiting. At the same time, however, just as with design and form, the function or behavior of the page must be separated from the content of the page. In this way we keep accessibility alive and our code can be reused in other cases for the same processes in the future that we need on particular pages we create now.
Wednesday, November 11, 2009
Document Object Model (DOM)
The Document Object Model (DOM) is used to define the parts of a document, be it HTML or other type. In the scope of JavaScript, the DOM is used to define what elements can be accessed using the scripting language and changed. The role of the DOM in web development is to define a standard so languages such as JavaScript can search through elements in a document and change them according to user input and other factors. Development of websites has become more dynamic due to the ability for change using scripting languages. This dynamic interface with the end user has created a more live approach to web surfing and presentation of content on the web. Users can get feedback based on input directly from these client-side scripted pages. Web browser vendors have developed browsers that can interact to provide the platform- and language-neutral interface features of the DOM to allow other languages to manipulate the contents displayed. Developing the DOM has enabled the expansion of multiple browsers because it sets a standard on which others can build and comply.
Following the specifications recommended by the W3C is in best practice just as obeying defined courtesy laws in traffic. If everyone developed a different solution to the object model, the referencing would be very browser-specific, and generally non-conformity leads to more confusion and lack of support. Drivers and developers alike rely on a system of conformity on which they comply to get the optimal results from the task at hand. The tested standard in place by the W3C, as defined, will result in the best compatibility between sites and browsers in the coming future. That is why standards are in place, and that is why we look to them as a foundation on which to build.
The DOM is something I've referenced and used without first knowing it existed. In the playground of development, getElementById was a necessary property on which I relied for changing a predefined web page to meet my personal taste. I didn't know as much then as I do now, but it was an adventure which helps me appreciate the DOM now. I can see its value in the development of browsers and in a world where no one can tell who will use what to access what is available. Just as I have previously stated, some choose to conform to and others to dictate to the masses of the development sector. W3C standards are generally dictations of what others should conform to when considering future development in the fields concerned, but as such, the dictations are generally derived from a collection of conformities collected over time and defined as best practice.
Following the specifications recommended by the W3C is in best practice just as obeying defined courtesy laws in traffic. If everyone developed a different solution to the object model, the referencing would be very browser-specific, and generally non-conformity leads to more confusion and lack of support. Drivers and developers alike rely on a system of conformity on which they comply to get the optimal results from the task at hand. The tested standard in place by the W3C, as defined, will result in the best compatibility between sites and browsers in the coming future. That is why standards are in place, and that is why we look to them as a foundation on which to build.
The DOM is something I've referenced and used without first knowing it existed. In the playground of development, getElementById was a necessary property on which I relied for changing a predefined web page to meet my personal taste. I didn't know as much then as I do now, but it was an adventure which helps me appreciate the DOM now. I can see its value in the development of browsers and in a world where no one can tell who will use what to access what is available. Just as I have previously stated, some choose to conform to and others to dictate to the masses of the development sector. W3C standards are generally dictations of what others should conform to when considering future development in the fields concerned, but as such, the dictations are generally derived from a collection of conformities collected over time and defined as best practice.
Tuesday, November 10, 2009
JavaScript
Developing with JavaScript for me is much like my previous semester where thoughts often fall into the categories of if and then decision-making for everyday life. I've had some previous experience decoding JavaScript for purposes of just playing around with possible code features on a website where users log in to view a page. I scripted the site so that if the user is in fact logged in then display the page, otherwise they will be redirected to the login page and will not be able to view the page requested. It was this that consisted of the first points of my interest in JavaScript, and I found myself browsing the W3C school website quite often to better understand the code for which I had no previous editing experience. I've begun again to think of different implementations for JavaScript, including authentication of users and form-filling features for users. I look toward the future a little more, where I see ASP and PHP web programming languages taking over the features we see in JavaScript, but not entirely replacing the use for it on the web.
JavaScript and Java are often confused. The basic difference is that a script is used to send instructions through a program to perform a task. Scripts are interpreted whereas Java, as a program language, must be compiled and decompiled using a program that must be installed on the computer. Scripting languages, like JavaScript and VBScript, are lighter in the sense of memory usage on the computer. Once a programmed language like Java loads it must run the decompiler for the entire duration of the program. In the case of JavaScript, the browser renders the script and interprets it as it comes across the code, and when the process is complete, the rendering of the script is over. JavaScript is used to accept and apply user input and can be changed by the user. Java is more of a static program when used online which cannot be changed, but instead has been packaged to meet a specified need before being distributed to be run by its own decompiler.
JavaScript, most formally although less widely known as ECMAScript or ECMA-262, was turned over to an international standards body in 1996, which then became responsible for subsequent development in the scripting language. The ability today for JavaScript to be separated from the content and presentation of the website has broadened its use and enabled developers to implement the features of JavaScript more thoroughly on the Web without limiting users from accessing the content intended. However, as of now, I cannot say I see the future in JavaScript. I have seen its uses for programming simple sites where no database is used, but the future lies in the database-driven website and JavaScript might be an afterthought.
JavaScript and Java are often confused. The basic difference is that a script is used to send instructions through a program to perform a task. Scripts are interpreted whereas Java, as a program language, must be compiled and decompiled using a program that must be installed on the computer. Scripting languages, like JavaScript and VBScript, are lighter in the sense of memory usage on the computer. Once a programmed language like Java loads it must run the decompiler for the entire duration of the program. In the case of JavaScript, the browser renders the script and interprets it as it comes across the code, and when the process is complete, the rendering of the script is over. JavaScript is used to accept and apply user input and can be changed by the user. Java is more of a static program when used online which cannot be changed, but instead has been packaged to meet a specified need before being distributed to be run by its own decompiler.
JavaScript, most formally although less widely known as ECMAScript or ECMA-262, was turned over to an international standards body in 1996, which then became responsible for subsequent development in the scripting language. The ability today for JavaScript to be separated from the content and presentation of the website has broadened its use and enabled developers to implement the features of JavaScript more thoroughly on the Web without limiting users from accessing the content intended. However, as of now, I cannot say I see the future in JavaScript. I have seen its uses for programming simple sites where no database is used, but the future lies in the database-driven website and JavaScript might be an afterthought.
Tuesday, October 13, 2009
CSS Future
The future CSS holds for the Internet community lies in the flexibility of design and structure. New and improved ways of building the background design of a page are mentioned in the article To Infinity and Beyond! by Alex Walker of sitepoint.com. The three things he mentions are multiple background images, background sizing and gradient fills.
Multiple background images make it easier for designing a site with a background fill and added effects for aesthetics. For instance, if a designer wanted to place a background image in the top left and bottom right corners of a division within the website, he/she would previously have had to create a separate division absolutely positioned over the top of the original with an image of considerable size with a transparent background which was positioned correctly so it would fit into the division. With multiple backgrounds, smaller, less cumbersome images can be used and positioned in place as needed within the division. Up to four may be used! As a web developer, I feel the future of multiple background images will help the simple design structure and contribute to an easier code for building sites.
Ironically, as I read the first topic of the article, I began thinking how it would be convenient if they had a 'stretch' property in background images. As it turns out, the background-size property with its values of currently proprietary nature can be used to stretch the image to a specific size. While sizing of images has not always produced very desired results, it can be a consideration for images with merely a fill design. I cannot say I can see this as useful now as I have not really had a need for it, but I do see its advantages.
Gradient fills are the way of the future. We speak of accessibility, and gradients are the answer to blocked images. We speak of flat-colored, boring websites, and gradients are there to provide the possibility for a sleek design without compromizing simplicity. The future of the web is likely changing with the design structure used with gradient backgrounds. I can see this being a great tool in my future design where one might need a header of one color to gradually fill out the rest of the page with another color without storing image files on the server. The coding process is less difficult and the possibilities for direction are less limited.
Reading the article did excite me for the future of the web, although we are still trying, as with most technology, to be 'backward compatible' to those who might not have the latest browsing or upgrade in computing. Accessibility includes the old systems and must therefore be included in the design thought and structure. However, as mentioned in the article, cross-browser techniques are ever prominent in ensuring the users with the latest equipment can take part in the design intended by devlopers of the age, while those not so fortunate will not be left without consideration... for now.
In consideration of where I stand in my knowledge of CSS and its many uses, I do believe I have made progress. I understand more how elements interact with each other, and I understand there are definitely some quirks that need to be worked through to achieve a desired effect when dealing with multiple browsers, and multiple versions of the same browser. Positioning of elements has been a challenge sometimes, but it gets better, as do most things, with a little practice. We all have a future ahead. Why not start now to include the future in it? The more I use the tools of the future, despite the complaints I may have of loss of mastery due to the change in upgrades, the more I realize that to be a resourceful candidate in the future of the computing and Internet world, I must understand what users are experiencing when they get upgrades. We have a playground in technology. It's the mystery of the unknown. It is playtime!
Multiple background images make it easier for designing a site with a background fill and added effects for aesthetics. For instance, if a designer wanted to place a background image in the top left and bottom right corners of a division within the website, he/she would previously have had to create a separate division absolutely positioned over the top of the original with an image of considerable size with a transparent background which was positioned correctly so it would fit into the division. With multiple backgrounds, smaller, less cumbersome images can be used and positioned in place as needed within the division. Up to four may be used! As a web developer, I feel the future of multiple background images will help the simple design structure and contribute to an easier code for building sites.
Ironically, as I read the first topic of the article, I began thinking how it would be convenient if they had a 'stretch' property in background images. As it turns out, the background-size property with its values of currently proprietary nature can be used to stretch the image to a specific size. While sizing of images has not always produced very desired results, it can be a consideration for images with merely a fill design. I cannot say I can see this as useful now as I have not really had a need for it, but I do see its advantages.
Gradient fills are the way of the future. We speak of accessibility, and gradients are the answer to blocked images. We speak of flat-colored, boring websites, and gradients are there to provide the possibility for a sleek design without compromizing simplicity. The future of the web is likely changing with the design structure used with gradient backgrounds. I can see this being a great tool in my future design where one might need a header of one color to gradually fill out the rest of the page with another color without storing image files on the server. The coding process is less difficult and the possibilities for direction are less limited.
Reading the article did excite me for the future of the web, although we are still trying, as with most technology, to be 'backward compatible' to those who might not have the latest browsing or upgrade in computing. Accessibility includes the old systems and must therefore be included in the design thought and structure. However, as mentioned in the article, cross-browser techniques are ever prominent in ensuring the users with the latest equipment can take part in the design intended by devlopers of the age, while those not so fortunate will not be left without consideration... for now.
In consideration of where I stand in my knowledge of CSS and its many uses, I do believe I have made progress. I understand more how elements interact with each other, and I understand there are definitely some quirks that need to be worked through to achieve a desired effect when dealing with multiple browsers, and multiple versions of the same browser. Positioning of elements has been a challenge sometimes, but it gets better, as do most things, with a little practice. We all have a future ahead. Why not start now to include the future in it? The more I use the tools of the future, despite the complaints I may have of loss of mastery due to the change in upgrades, the more I realize that to be a resourceful candidate in the future of the computing and Internet world, I must understand what users are experiencing when they get upgrades. We have a playground in technology. It's the mystery of the unknown. It is playtime!
Monday, October 5, 2009
Accessibility
Web accessibility is made ever-increasingly easy with the use of separation of web layers. Text-only devices rely on accessibility techniques for displaying and relaying content for users without the regular means of graphics for understanding web content. The cause for this could be a number of things including mobile users, visually impaired users (including those with color-differentiating restrictions), restricted browers (disabling pictures, JavaScript, etc.), and those with difficulties in the navigational use of computer input devices. An increasingly dense older population has called for a simplified layout in web content which helps users, who might have not been engulfed in the Information Age since birth, achieve the highest level of understanding for where navigation, links, and interactive interfaces can be found and how each site should function. Accessible websites are important to reaching out to the entire web audience without discriminating against those with less ability than others. Using the proper syntax and layout of a website can better enable users of all walks of life to find what they are looking for and to do so without feeling a need to look elsewhere for a more accessible site.
The Web Accessibiliy Initiative (WAI) by W3C has published Web Content Accessibility Guildelines to help with accessibility in a website and give developers a guide on which to base their sites. These guidelines are a basis for what can be considered appropriate when questioning whether a site is most accessibly developed.
The Web Accessibiliy Initiative (WAI) by W3C has published Web Content Accessibility Guildelines to help with accessibility in a website and give developers a guide on which to base their sites. These guidelines are a basis for what can be considered appropriate when questioning whether a site is most accessibly developed.
Subscribe to:
Posts (Atom)