Please create an account to participate in the Slashdot moderation system

typodupeerror

## Journal: Test Taking Strategies

Following a thread recently posted, binomal distribution answers the 'how many I need to get right' question. Say that I am a slacker and only want a 70% on a 40 question 4 answer, multiple choice test. For some odd reason, people would think that I would require to learn 18 questions.

40 * 70% = 28

40 * 25% = 10

28 - 10 = 18

However, if we follow binomal distribution...

f(x,n,p) = [n x]*p^x*(1-p)^(n-x) where x is number of trials, n is number of successes and p is chance of success.

f(40,0...7,.25)=.18

1-.18=.82

28-8=20

So, if I want at 70 or higher on my exam with a 82% chance of succeeding, I want to know 20 questions. Same principle says to make a 90, I need to know 28 questions, not 26.

## Journal: Report Design - Flat Report

One skill on my skill set is Report Design. Having done a significant amount of report creation of functional and end-users, I have some definite opinions on how to create a report. In this installment, I plan to cover flat reports, the basic reports that list data.

Where I work, we deliver a large amount of reports using HTML. Our BI portal is cutting edge, being based off of Infor's MPC product, which itself is built upon Microsoft's technology, specifically .Net, SQL Server, Analysis Services, and ASP. Our standard method of creating a report is to grab the dimensions from the MPC Applet and port out the data through XML. We take the XML doc and transform it using pretty vanilla XSL and CSS.

After some user analysis, we decided the best methodology of design is to flip the report from the standard. Most analysis type personnel, like Accountants, expect to see a grid of data with the totals at the bottom and subtotal breaks throughout the report. Unfortunately, I found that most end users, the real consumers of the report, would print the report, sometimes to the tune of 1000 pages, and look at the last page to see the total of the report. If that total looked good, then the user would toss the report. Otherwise, the user would flip through the pages looking for a subtotal that looked wrong. The user would then save that section and throw away the rest.

In tackling this problem, I conceived of putting the report total at the top of the report, just under the title. This would put it on the first "screen" of the report in a browser. Next is a hyperlink back to the page containing the original applet. After that, I put the subtotals in a table. These subtotals are linked to the actual subsections of the report. Finally, each subsection has a like to go to the top of the page. This aides in navigation on the page and seems to encourage most users from printing out the page.

The design was highly embraced by my end-users. I had some issues with certain accountants because they were not wanting to 'embrace change'. In other words, they wanted to whine. However, they came to enjoy the reports after some working with some of them.