Please, read the rest of this page and the links soon and get any questions answered early-on. They form the specs for the HOL project and will be considered as it is graded. Meanwhile, you can jump to the stuff about Logging On to INFO300.NET to find steps for logging into info300.net and working at the command line...
Or, propose a topic not listed that interests you more.
Topics will be approved in class during roll call, which will be random. No topic will be approved for more than two students in a class except at the first roll call. There is only one Tech Marketplace Brief due this semester, not two as in some examples. Pick a topic for which you'd like to run down facts: brief description of the technology and its history; size of the market in $ and/or # of units; manufacturers and their share of the market; expectations for the next few years. If you cannot find market facts for your approved topic, ask about another.
The marked up references are most important for the 'Term Paper' portion of the project, more important than the brief you write, so please be printing and highlighting market facts on printed copies of pages referenced as you discover and organize your facts. Make sure the marked-up pages include links or citations that lead to the original articles. Only copy/print pages with facts on them -- for example, if you read a ten page article to get background on your technology but only two of the pages had facts pertinent to your tech market brief, only print and mark up those two pages.
Don't ignore Wikipedia and other obvious on-line sources like cio.com, gizmodo, or arstechnica as you research about your technology's market, and don't leave them out of your list of references. Note: It is not required to print out pages with descriptions and history of the technology found at Wikipedia or oth. Please, take care to provide marked up, printed pages to support your market facts or forecasts.
Do dig deeper with Gartner, the Library, WSJ, and other more scholarly databases available to IS majors. Look for convincing graphics dated this year or last. The instructor, and the eventual user of your Portfolio, is most interested in seeing current facts about market share or important, current, advances in the tech that will affect the marketplace.
tail -f /var/log/httpd/error_log | grep loginidReplace 'loginid' with your login id to grep out the errors for your login. 'tail' shows the end of a file, the '-f' means 'follow' so any new errors will show up. Use ctrl-c to stop following the log. Here's an example with more than one terminal window open:
See the announcements at the top of the class' page for due dates.
This part of the project involves learning to work on a server at the command line and to use vi-Visual Editor. Parts of it are scored automatically on your class' Progress Page at info300.net. Points are scored for having the right parts in the right places and the right time.
It is an opportunity to use a Linux server at the command line to gain entry-level skills with unix commands, permissions, and the vi editor. The website, some screenshots of your work at the command line, clearly marked up XHTML, and the Tech Brief make good entries for a portfolio. Every year I hear from several grads who credit meeting the specs for this exercise for their exploration of Linux and landing their job in IT. Please don't say things to me like "but it's quicker if I use Notepad and FileZilla" as you work though this project because it is an exercise in using the command line and vi.
Parts of the project are scored automatically. The class' progress pages are updated at about one second past every minute:
Here are last semester's Progress Pages:
The specs for the project's websites include 'mobile-first' or 'responsive' features. A mobile-first site is easier and will be considered for max points. A responsive site that is mobile friendly and uses @media queries to adapt to phones, tablets, or desktop browser will be more valuable in a portfolio.
'Mobile-First' means designing a website so it renders the best on mobile-devices without the user needing to stretch or resize the display. The problem with making a site 'mobile only' is that it may not use the space in a full-sized browser effectively.
'Responsive' means the pages also render well on tablets and full-sized browsers. In 2015, Google is dropping 'mobile unfriendly' sites from the results of queries from mobile devices so they are helping to spur the transition from XHTML and CSS to HTML5 and CSS3 to provide mobile-friendly and responsive websites.
Some websites are 'adaptive'. They have different HTML and CSS for two or three different sized browsers, use data transmitted with the browser's web request to determine the browser in use, then serve up the version of the website appropriate for that device. Adaptive sites are more expensive to develop and don't respond to differences like 'phone or phablet', rotating the phone to landscape, or resizing the browser.
'Viewport', '@media queries', 'break points', 'collapsible grids' and other responsive features in HTML5 and CSS3 are key to making websites that work on the small display of a smartphone and also on larger tablets and full-sized desktop or notebook browsers. 'Responsive' is generally accepted as the best way to make websites these days. It results in a pleasing experience across platforms and is less expensive to develop, especially if a 'responsive framework' is used in the design.
The instructor provides This Example of a Responsive, Mobile-friendly Site. It was built using the tutorial at W3Schools CSS Responsive. It improves the tutorial by using semantic page markup instead of divs with similar names. Look for these elements in the page source: header, nav, main, aside, blockquote, and footer. The W3School RWD tute is one of the simplest about responsive design and is recommended as a starting point. The code may be copied from a browser, and is avaialable from the command line at info300 in /home/Resp/web.
There are lots of other sites devoted to techniques for mobile-friendly and responsive sites. Google's Mobile Guide is an excellent option that shouldn't be ignored.
Mozilla's site for Responsive Design has it all, is a very complete reference with excellent tutes that go beyond W3Schools. Check out the Web Guide's home page for other topics of interest to IS pros.
Inventing the CSS and HTML to make a responsive site work on all browsers is a challenging task, especially for a noob to the environment. The W3School's 'CSS Responsive' site is a good way to learn the key concepts that make sites mobile friendly and responsive.
Adopting a 'framework' proven to work across browsers and devices is probably a better idea after you understand responsive features of CSS. Frameworks can greatly reduce the amount of time it takes to develop a responsive site and avoid 'cross browser incompatibilities' that can chew up hours of a developer's time. The frameworks' authors have used their expertise to 'normalize' their framework's CSS for 'cross browser compatibility' that is difficult to achieve as HTML5 and CSS3 are still an emerging standard. Inventing your own responsive scheme is also a good idea if you've got time and inclination.
There are several well-known responsive frameworks from 'light' to 'heavy'. The tradeoff is between download speed and visual appeal. Google recommends designing for speed, but dynamic effects enhance the appearance and appeal of web pages. Here are some well-used frameworks:
Investigate the templates, design, and sizzle-factor of these frameworks and choose one to adopt, or decide to roll your own after you've seen how they work. Some frameworks use 'SASS' or other language of their own to define and edit CSS or HTML -- the instructor doesn't use these, believes they obfuscate the technology at hand, and is in a job where the basic elements are taught. Many web developers embrace these other tools and claim they're more productive with them...
Check out the CSS Zen Garden for some responsive CSS inspiration. All the exhibits show off CSS3 design using exactly the same html.
Most interest in web-development in recent years is in making sites that render and work equally well on a all sizes of browser from older/cheaper smartphones (320 pixels) through a full-sized browser (1920+ pixels). More and more access to websites is from smartphones so it makes sense to cater to their smallish 'viewports'. 'Mobile First' web design means making the HTML and CSS to that the site looks and works the best for mobile devices without the user needing to stretch or double-tap the screen to read it or use it by keying in data or touching buttons and links. Then, the site can be tweaked to make it suit larger devices, too. Generally, the analysis and focus on making a better 'small screen experience' helps improve the experience on a larger browser, too.
Another approach to this is to build more than one version of the website and serve up the version appropriate for the 'user agent' that requests the page. These 'adaptive' sites are easy to find on-line where the 'full version' for a desktop has content formatted and placed for large browser windows. A 'mobile version' appears when the user agent is a phone or tablet and a 'full' or 'desktop' version appears when the user agent is full-sized on a notebook or desktop. This is relatively expensive and might not accommodate larger phones, phablets, or tablets where the user has sharp vision and would rather see the full-sized page regardless of how their device shows up at the server as 'user agent'. Also, 'adaptive' doesn't accommodate changes in the width of the browser when a phone is turned on its side or a desktop browser is resized.
'Material Design', promoted by Google, is a current technique to make web pages better looking and more 'intuitive' to use. Of course, 'flat design' has its proponents, too. Subtle, or obvious, use of material design is included in Google's Materialize Framework and in some of the lightweight frameworks as 'cards' using css border and shadow properties that are simple to render and consume no bandwidth. Material Design can be a powerful visual aid for sighted folks who use the site. Coupled with semantic markup, materials can provide the best organization for search engines, blind, and sighted web browsers.
Please learn vi before considering another text editor. The project encourages use of the Linux command line and vi editor to gain practice with these valuable skills.
Vi and other professional editors do 'syntax highlighting' for HTML, CSS, and several programming languages. Syntax highlighting is essential for pro-quality work. It marks the beginnings and ends of structures in code or documents, shows clearly where quotes, parentheses, squiggly brackets, or angle brackets are left open, different colors are used for elements of the language, variables, and other features of the language being edited. Syntax highlighting makes it easy to see and avoid problems that can be difficult or impossible to debug with an editor like NotePad, built into Windows.
Many web developers work with vi and claim it's the quickest and most available editor, after it's been learned it is a fully-featured editor that can be accessed most anywhere there is a command line to edit files 'in place' on the server.
Many other web pros use a desktop editor optimized for the work at hand. Sometimes, command line access isn't available, as in 'hosting services' where access is via sftp and a menu. NotePad++ is one of the simplest. Atom, Code Wrangler, Sublime, and others of the Best Code Editors in 2015 should only be considered after you've master command-line tools! But, they should be considered...
With these desktop/notebook application, a file copy program like FileZilla is used to copy files to the desktop for editing and copying files back to the server to publish them. FileZilla may be customized to use your editor of choice when files are selected to 'view and edit' from the right-click menu -- when changes are saved on the desktop copy the files are queued up for FileZilla to copy back to the server. Some of the editors include features for sftp so that you can publish the file to the server without using FileZilla.
Some features of the heavier frameworks require a web-server environment so the features will work. In these cases a WAMP-Windows Apache MySQL PHP server can be installed on a Windows machine, or XAMP on an OSX notebook or desktop, to make a 'personal web server' available for development and debugging.
'Semantic Markup' means using HTML elements to show the 'semantics' or 'how words are used' on a page. Search engines need semantic markup to figure out what a page 'means' so they show up when a web browser searches. Blind people need it so that they can use their 'page reader' to index and navigate the page. Sighted people who can see the content can work out the semantics more-or-less easily, but also benefit from semantic markup.
Googling 'semantic markup' will get lots of discussions about it. Molly Holzchlag, one of the Founding Mothers of the WWW has published lots about it, like this article: Semantics in XHTML.
Operationally, it means:
HTML5 has added a few other acceptable tags: article, section, header, footer, aside, details, code, and nav are most welcome. There are also new elements defined for HTML FORM elements, and markup appropriate for publishing that has been missing in XHTML.
Use View -> Source on this example of a winning project from the past, which is not mobile-friendly or responsive. This gentleman found several facts and edited them into a file named Brief1 in his Outlines directory; made a website semantically marked up to agree with the outline; and submitted well-researched briefs of about 6 or 8 pages each, and posted these abstracts on-line. (This semester's project only requires one brief, but has requirements for accessibility and SEO.) Every deadline was met, and there were a several pages of 'highlighted facts' that were very useful in updating this elder geek about these well-known products and manufacturers. No time was wasted on fancy effects, but it reeks of a careful reading of the specs and serves as a clear example. You might want more pizzazz or subtle effects for your web-design portfolio, but this got max points for the class.
To access the server's command line: Mac users already have a 'Terminal Window' on their desktop and SSH-Secure Shell in their operating system. Windows users need to download putty.exe. The Chrome browser has extensions for Secure Shell and SFTP Clients -- these showed up during 2014 and _may_ be the answer for ChromeBook users. iPhone users can get the 'Server Auditor' from the Apple store to gain command line access via their iPhone. Android users can get ConnectBot from the Play Store, or review and choose any of the dozens of other options. Some students become adept with their phone's SSH client and virtual keyboard and complete the project that way -- I think that's a valuable skill, have used my Droid several times to rescue a customer's server...
Unix's vi-Visual Editor is a 'server side editor' available from the command line when you log into info300.net. It's a standards-compliant component of any flavor of unix and is the only editor in the 'minimal installation' used for many unix/linux virtual or otherwise headless servers. Vi is compatible with putty.exe, Mac's Terminal, Windows TinyTerm, dumb tubes, and the SSH clients mentioned above for smartphones. Tablet/phone users will need to figure out how to do the Ctrl-shift and the Esc key on the virtual keyboard -- some students have made their whole project by thumbing their smartphone.
Vi is 'scriptable' so learning it is invaluable for system programming and management tasks in an *ix environment. It's easy to put vi in recording mode and make an editable 'macro' that can be invoked from either a script or from vi's multi-key command mode. All unix's redirects, greps, regex, and pipes connect through vi, making it a good choice when administrative scripts require editing stuff in local or remote files.
Find a tutorial you like and learn vi's 'modes' and the few commands needed for the HOL project. info300.net runs vim-vi Improved instead of plain old vi, so if you search for 'vim tutorial' you don't miss out on the modern improvements to this venerable, 40+ year-old unix component. Here are some good links for learning vi/vim:
Other considerations and resources:
Timely delivery is one of the essential requirements for both these exercises. Progress not demo'd on the class' Progress Pages by the time due will get zero points. Late papers will be docked five points for delivery after the class meeting where they are due and another point deducted for each midnight that passes before delivery.
Due dates for each component will be announced as the project is assigned.