Application Form—Due May 1, 2014

Faculty Learning Community Fall 2014 through Spring 2015

iTeach: Using Tablet Computers in the Classroom

Faculty Co-Facilitators: Donald Snyder, Media and Communication Studies and Co-Facilitator to be announced

Since its introduction in 2010, Apple has successfully marketed the iPad to teachers and students as an emerging device that will enhance the educational process. The specific strengths of the iPad include its relative affordability, increased mobility, and expansive catalogue of applications that are potentially valuable as educational tools. The iPad also provides users with a simplified path into the world of digital production.

The purpose of this two semester faculty learning community is to explore the various ways in which teachers can utilize iPads (and other non-Apple tablets) in their classrooms. Participants will orient themselves with various education and digital production apps, sharing how the iPad can become a valuable asset in their courses (planning, content delivery, and creative production). The primary goal is for participants to strengthen their capacity to use iPads for instructional practice. To this end, as a specific deliverable, participants will develop, implement, and assess at least one new lesson (or modify an existing lesson) that makes specific use of tablet computing to support the lesson’s content objective. This lesson plan will include strategies for assessing and evaluating how using this technology specifically impacts student learning.

Name:______________________________

Office Phone:______________________________

Department:______________________________

Email Address:______________________________

Course(s) that you teach: ___________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Status:

____ Tenure-track faculty

____ Lecturer/ Senior Lecturer

____ Part-time faculty / Adjunct

Number of years teaching/working at UMBC: ______

Please provide a response to the following questions on a separate sheet of paper:

1. Why do you wish to participate in this Community?

2. What (if any) experiences have you had experimenting with tablets in your classrooms? If you have not had any experience, what outcomes do you hope the implementation of tablets will help promote?

3. Please provide information on which generation iPad or tablet you have access to.

Please send an electronic copy of your application to The Faculty Development Center at Lhodges@umbc.edu. Please attach a schedule grid with weekly time availability for FLC meetings and a confirmed fall semester schedule if available.

Applicant’s Signature

If I am selected as a participant in the Faculty Learning Community, iTeach: Using Tablet Computers in the Classroom, I agree to participate fully in the community’s activities.I will participate in the meetings, readings, projects, and reports associated with this learning community. I will share ideas and materials generated with other faculty members.

_____________________________________________________             ____________

Applicant’s Signature                                                            Date

Department Chair’s/Supervisor’s Signature

I endorse the above applicant’s participation in the Faculty Learning Community,and will value the curricular and pedagogical work completed by acknowledging the time commitment required by the FLC.

_____________________________________________________             ____________

Chair’s/Supervisor’s Signature                                           Date

Check List:

Schedule grid _____

Chairperson signature _____

Application Form _____

(Figure out how to fill up the freelance pig. Photo by Mike Tungate / Flickr)

If there’s one question I’m asked by web designers and developers more than any other, it’s how to figure out what to charge for a freelance project. Sure, we want to be fair to the client. But we also want to be fair to ourselves and make a reasonable profit. It’s never a happy time to finish a design or development project and realize we lost our shirt.

There are several ways web freelancers estimate projects. They can charge by the hour, by the project, by retainer, by bartering, by cost per page, or even by a percentage of sales.

The most common methods, by far, are by the hour and by the project. Retainers are less common, but certainly a method to consider for site maintenance, updates to code and designs, email marketing and other ongoing projects and tasks. Bartering is less common, but it does tend to come up, especially for startup clients that are, shall we say, budget-challenged.

Free trial on Treehouse: Do you want to sharpen your web design and development skills? Click here to try a free 14-day trial on Treehouse.

Page rates can be easy to estimate, but there’s always the real risk of scope-creep that eats into profits. That can easily happen when there’s a poorly written contract or, worse, no contract. Being paid a percentage of sales may sound attractive, particularly when the client is selling high-end (read: expensive) products or services. But that type of arrangement can come with a nagging notion in the back of one’s mind that’s difficult to police: Is the client telling the truth about sales numbers?

Winning the Freelance Estimating Game

Whether you plan to bill by the hour, project or retainer, you must know your specific hourly rate to generate accurate estimates. Not the other guy’s or gal’s. Not the going rate. Your rate.

You need to recoup the cost of your time, overhead and also make a profit. In its simplest terms, profit is the money that’s left over after paying yourself and your bills. It allows your business to grow, buy a new monitor when the one you have flickers its last, buy other needed items or put it away for a rainy day.

For many designers, billing a website design project by the hour makes a lot of sense. It’s easy and doesn’t require a lot of arithmetic. Some designers take their best guess at what others are charging or what they think the client might be willing to pay. Others simply pull a number out of the air. All are bad ideas.

Why?

You’re unique. Yup, just like every other web designer or developer out there. We all have different setups and our costs vary. Calculating your true hourly rate is a critical exercise to ensure your success and profitability. Your hourly rate should address your target salary, called a draw if you’re a sole proprietor. Sole proprietors don’t usually have a regular salary. Your rate must also account for your overhead and profit target.

Figuring your hourly rate isn’t too tough, but it does require tapping into some of that elementary school math you complained you’d never use.

The Place to Start Is You

What’s your target salary? Even if you’ll be taking a draw, it’s a good idea to have a pre-set amount you’ll draw from the business on a regular basis. It makes both your business and personal money management easier.

Be realistic when coming up with a salary number. Sure, you’re in business to make money, but shooting for a six-figure salary might not be in the cards, at least for your first few years in business. If you’re currently gainfully employed, start with a target that matches or is slightly below your current position’s salary. For the purpose of the following example calculation, I’ll use $40,000.

Keep in mind that the figures I’m using for this example may not match what you make or what you pay for overhead in your life. But they should give you great insight into the process.

On top of your target salary or draw, you’ll need to figure in other associated costs including taxes, FICA (Social Security in the United States), insurance and more. A safe figure is 25 percent to 30 percent. I lean toward 30 percent. The math looks like this:

Salary: $40,000

Associated costs at 30 percent of salary: $12,000

Total: $52,000

Next, we’ll need to know how many hours there are in a work year. I’ll save you the trouble of digging out that calculator. It’s 2,080 hours.

If you’re like most people, you probably would like to spend a few holidays with the family and you may get a bad cold now and then and need to take a day off. Let’s factor those things into our equation.

7 legal holidays (U.S.): 56 hours (8 x 7)

2 weeks vacation: 80 hours (8 x 10)

5 sick days: 40 hours (8 x 5)

Total: 176 hours

Subtract that from the total hours and we’re left with 1,904 billable hours. But you probably do other things around the office, such as invoicing, sales calls, surfing the internet and playing solitaire. You can’t bill for that time, so we’ll need to subtract those hours. Ideally, you’ve kept time sheets. A review of a few weeks can give you a pretty good idea how much non-billable time you average. If you haven’t kept time sheets, you’ll have to give it your best guess and make some adjustments later on when you have some documentation.

A typical target is 25 percent. For those new to web design or development freelance work, it may be as much as 50 percent. Hopefully it’s not more than that.

I’ll use 25 percent for this example. That brings our billable hours into the more realistic area of 1,428 per year. All you need to do is simply divide your billable hours into the cost of salaries and voila! You have a rate of $36.41 ($52,000/1,428). Let’s round that down to $36. This is the amount to must charge to recover your salary and its associated costs.

Get a Handle on Your Overhead

To do the job, though, we’ll need some stuff. Most web designers and developers – like all freelancers – need office rent or home office costs, utilities, phones, tablets, computers, software, paper, ink, marketing materials and so on. The accountants like to call this overhead. I guess that’s because if you buy too much stuff, you’ll find yourself in way over your head.

Allow me to pull a number out of the air. Say, for our example, your overhead costs $35,000 per year. We need to find the percentage of salaries this overhead represents. Simple. Divide the overhead ($35,000) by the salary ($52,000) and you come up with a little better than 67 percent. Add this to the base rate we calculated earlier:

$36 X 67 percent = $24.12

$36 plus $24.12 for overhead comes to $60.12.

Again, we’ll round that out to a clean $60.

And there you have it. Now you know you’ll need to charge at least $60 per hour if you want to eat on occasion, pay the rent and buy various supplies. We also know that we need to contract at least 1,428 hours per year, or 119 hours each month, to make this mark. We not only solved our rate problem, we also set a sales goal. That’s a pretty handy piece of information to have as a byproduct of your mathematical efforts.

Whew! You’re Almost Done

There’s one more thing. We covered the target salary and overhead, but we also need to make a profit.

How much profit do we need? I’d say not to go below 10 percent. Twenty percent is better and that’s what we’ll use for our target. Time to pull out the calculator again. We’ve established our base rate at $60. Twenty percent of $60 is $12, so we need to tack $12 on top. Our final rate, to recover salaries, overhead and a healthy profit, is $72. If you’re like me, you’ll round this amount up to a tidy $75. It just sounds better and adds a slight fudge factor.

This final rate is the number you’ll use to do your estimating, whether you charge by the hour or by the job. It’s the number you can’t afford to go below. No more wondering if you can afford to take on this job or decline that one. You have facts to back up your decisions.

With your real hourly rate and some previous time sheets in hand, you’re all set to start estimating like a pro who can back up project estimates with confidence.

Neil Tortorella is a graphic designer, writer and marketing consultant. He’s the author of “Starting Your Career as a Freelance Web Designer” and runs Tortorella Design from his home in Fort Lauderdale, Fla.

The post How to Calculate Hourly Freelance Rates for Web Design, Development Work appeared first on Treehouse Blog.

by Sara Leidner

Managing z-index across large sites can be a pain in the butt. CSS is hard to test, so it's notoriously easy to make a change that ends up, for instance, hiding some important UI under who-knows-where.

If you use a CSS preprocessor, maybe we can handle it in a special way.

An Idea From Game Programming

Vertical stacking order is not only a problem for web design, it's a major issue for game developers too. They work in even more dynamic environments where it is vitally important which things appear on top of others.

In a brief conversation with Ryan Campbell, who is digging into the world of games, he says the way it's normally handled is a enum (kind of like a named array of constants) variable which then you reference as needed.

Here's an example of some code he might use:

typedef enum : uint16_t {
      WorldLayerGround             = 100,
      WorldLayerBelowCharacter     = 200,
      WorldLayerAboveCharacter     = 400,
      WorldLayerTop                = 800,
      WorldLayerCount              = 1600
    } WorldLayer;

That is defined in a file dedicated to declaring constants for the game to use. Notice how:

1. They are all declared together
2. There is space left between the numbers

It's fairly common to see people number in the hundreds with z-index in web design too. The idea being that you could slip something in between later if need be, which you couldn't if you did 1, 2, 3, etc, because z-index doesn't support decimals. But rarely do you see z-index declared in a group like that. Seems like a smart idea to me!

Grouping

The idea is that all the code that controls vertical stacking is in one place. You could just put all that stuff together.

.modal {
      z-index: 9000;
    }
    .overlay {
      z-index: 8000;
    }
    .header {
      z-index: 7000;
    }

But I'm not a huge fan of that. I don't like duplicating selectors throughout stylesheets just for organization. Just a personal preference. When I find where a class is defined, everything that that class does is there.

Perhaps we can do the same thing but just with the values...

A z-index Partial

Perhaps the single most useful feature of preprocessors is the ability to do includes. Smush multiple files together into one output file. That means you can organize your CSS however makes sense to you, which almost surely means breaking down into small, modular bits.

Maybe you already have a variables.styl or constants.less or something. You could get even more modular and have a file just for managing z-index. In SCSS, the typical naming convention for files only meant to be included start with an underscore, so we'd make a _zindex.scss.

In that file, you'd declare variables that contain all the z-index values you use throughout the site.

$zindexModal   : 9000;
    $zindexOverlay : 8000;
    $zindexHeader  : 7000;

Then in your global set of includes for other SCSS files, you always have this available:

@import "zindex";

And use them as needed:

.header {
       z-index: $zindexHeader;
    }

The idea would be go absolutely whole-hog on this. Do not declare z-index anywhere without making a variable for it and placing it within the stack in the _zindex.scss file.

Maps might be cleaner

Same idea, but using a Sass map instead of individual global variables:

$zindex: (
      modal     : 9000, 
      overlay   : 8000,
      dropdown  : 7000,
      header    : 6000,
      footer    : 5000
    );
    
    .header {
      z-index: map-get($zindex, header);
    }

I think I'll be converting sites over to this system. I don't see any downside and plenty of upsides.

Handling z-index is a post from CSS-Tricks