Rev Mentor

Tips, tricks, news & commentary for Revolution developers 
Filed under

revolution

 

YCombinator's push for iPad dev projects

RFS 6: iPad Applications

Most people think the important thing about the iPad is its form factor: that it's fundamentally a tablet computer. We think Apple has bigger ambitions. We think the iPad is meant to be a Windows killer. Or more precisely, a Windows transcender. We think Apple foresees a future in which the iPad is the default way people do what they now do with computers (and some other new things).

Programmers may never want a computer they don't control, but ordinary people just want something cheap that works. And that's how the iPad will seem to them. Many will never make a conscious decision to switch. They'll get an iPad as well, then find they use their Windows machine less and less. When it dies they won't replace it.

Will this future happen? It could. And if it does it will bring big changes. There will need to be iPad alternatives for all the things people now do on PCs. That could mean more than just replacing all the desktop software, because there may be things PC users now do with web apps that might be better done with native iPad apps.

Plus like any new platform the iPad will allow new types of applications that don't have any present day analogues. And no one knows now what most of them will be. Only people who become iPad developers will even think of these ideas, just as only microcomputer developers were in a position to think of the spreadsheet. Education and games may be areas where there are a lot of new ideas.

One particularly interesting subproblem is how to introduce iPads into big companies. This will probably have to be done by stealth initially, as happened with microcomputers. They'll have to be introduced as something individuals use, and which doesn't really count as a computer and thus can't be vetoed by the IT department. Don't worry about this; it's just a little tablet computer.

See also: RFS 5: Development on Handhelds

via ycombinator.com

Someone is actually putting their money where their mouth is: a respected funding group who wants to back iPad projects.

Rev developers who got an alpha of revMobile that creates now-dead Windows Mobile apps will want to pay attention to this. The question is: what is Runtime Revolution doing about it? My ear is to the ground, yours probably is as well.

Should we be getting familiar with Cocoa Touch and brushing up on our Objective-C?

Loading mentions Retweet
Filed under  //   capital   ipad   projects   revmobile   revolution   runtime revolution   vc   venture   windows mobile   ycombinator  
Posted by Jerry Daniels 

Comments [0]

Scary but good: profs rewrite text books

Readers can modify content on the Web, so why not in books?

A psychology book as seen on DynamicBooks. Macmillan plans to start selling 100 titles in this fashion in August.

In a kind of Wikipedia of textbooks, Macmillan, one of the five largest publishers of trade books and textbooks, is introducing software called DynamicBooks, which will allow college instructors to edit digital editions of textbooks and customize them for their individual classes.

Professors will be able to reorganize or delete chapters; upload course syllabuses, notes, videos, pictures and graphs; and perhaps most notably, rewrite or delete individual paragraphs, equations or illustrations.

While many publishers have offered customized print textbooks for years — allowing instructors to reorder chapters or insert third-party content from other publications or their own writing — DynamicBooks gives instructors the power to alter individual sentences and paragraphs without consulting the original authors or publisher.

"Basically they will go online, log on to the authoring tool, have the content right there and make whatever changes they want," said Brian Napack, president of Macmillan. "And we don't even look at it."

In August, Macmillan plans to start selling 100 titles through DynamicBooks. Students will be able to buy the e-books at dynamicbooks.com, in college bookstores and through CourseSmart, a joint venture among five textbook publishers that sells electronic textbooks. The DynamicBooks editions — which can be reached online or downloaded — can be read on laptops and the iPhone from Apple. Clancy Marshall, general manager of DynamicBooks, said the company planned to negotiate agreements with Apple so the electronic books could be read on the iPad.

The modifiable e-book editions will be much cheaper than traditional print textbooks. Psychology, for example, which has a list price of $134.29 (available on Barnes & Noble's Web site for $122.73), will sell for $48.76 in the DynamicBooks version. Macmillan is also offering print-on-demand versions of the customized books, which will be priced closer to traditional textbooks.

Fritz Foy, senior vice president for digital content at Macmillan, said the company expected e-book sales to replace the sales of used books. Part of the reason publishers charge high prices for traditional textbooks is that students usually resell them in the used market for several years before a new edition is released. DynamicBooks, Mr. Foy said, will be "semester and classroom specific," and the lower price, he said, should attract students who might otherwise look for used or even pirated editions.

Instructors who have tested the DynamicBooks software say they like the idea of being able to fine-tune a textbook. "There's almost always some piece here or some piece there that a faculty person would have rather done differently," said Todd Ruskell, senior lecturer in physics at the Colorado School of Mines, who tested an electronic edition of Physics for Scientists and Engineers by Paul A. Tipler and Gene Mosca.

Frank Lyman, executive vice president of CourseSmart, said he expected that some professors would embrace the opportunity to customize e-books but that most would continue to rely on traditional textbooks.

"For many instructors, that's very helpful to know it's been through a process and represents a best practice in terms of a particular curriculum," he said.

Even other publishers that allow instructors some level of customization hesitate about permitting changes at the sentence and paragraph level.

"There is a flow to books, and there's voice to them," said Don Kilburn, chief executive of Pearson Learning Solutions, which does allow instructors to change chapter orders and insert material from other sources. Mr. Kilburn said he had not been briefed on Macmillan's plans.

Mr. Ruskell said he did not change much in the physics textbook he tested with DynamicBooks. "You don't just want to say, 'Oh, I don't like this, I'm going to do this instead,' " he said. "You really want to think about it."

Mr. Comins, an author of Discovering the Universe, a popular astronomy textbook, said the new e-book program was a way to speed up the process for incorporating suggestions that he often receives while revising new print editions. "I've learned as an author over the years that I am not perfect,%" he said. "So if somebody in Iowa sees something in my book that they perceive is wrong, I am absolutely willing to give them the benefit of the doubt."

On the other hand, if an instructor decided to rewrite paragraphs about the origins of the universe from a religious rather than an evolutionary perspective, he said, "I would absolutely, positively be livid."

Ms. Clancy of Macmillan said the publisher reserved the right to "remove anything that is considered offensive or plagiarism," and would rely on students, parents and other instructors to help monitor changes.

There was (or is) a Revolution wiki development group. If folks have plans for doing a wiki or ebooks in Revolution, this article is good food for thought.

As an author, it's very challenging to think of strangers editing your work, but maybe it's time to embrace the change? The times, they are a-changin'.

Loading mentions Retweet
Filed under  //   books   ebooks   editing   ipad   macmillan   professors   revolution   scary   text   textbooks   wiki  
Posted by Jerry Daniels 

Comments [1]

What iPad Apps Are Going to Feel Like

Want to know what freshly developed apps for the iPad are going to feel like? Looking through Apple's iPad User Experience Guidelines is surprisingly revealing.

Some of the key points Apple's pushing on app developers for the iPad, and how Apple thinks their apps should behave:

They want apps to work no matter how you hold the iPad: "Your application should encourage people to interact with iPad from any side by providing a great experience in all orientations."

They don't want applications to just be bigger: "The best iPad applications give people innovative ways to interact with content while they perform a clearly defined, finite task. Resist the temptation to fill the large screen with features that are not directly related to the main task. In particular, you should not view the large iPad screen as an invitation to bring back all the functionality you pruned from your iPhone application." That's some straight talk.

They're super into the sharing thing: "Think of ways people might want to use your application with others. Expand your thinking to include both the physical sharing of a single device and the virtual sharing of data."

The oddly "realistic" bookshelf in iBooks isn't a fluke: "Consider a more real-world vision of your application. For example, on iPhone, Contacts is a streamlined list, but on iPad, Contacts is an address book with a beautifully tangible look and feel."

Multi-finger gestures will abound: "The large iPad screen provides great scope for multifinger gestures, including gestures made by more than one person."

It shouldn't feel like a computer, even if the iPad lets you do computer-y things with files now: "Although iPad applications can allow people to create and manipulate files and share them with a computer (when the device is docked), this does not mean that people should have a sense of the file system on iPad."

Starting to get a sense of things, and how apps are going to feel vs. their iPhone counterparts? There's more guidelines, like on how to use popovers, over at UX Mag. [Apple, UXMag]

The concepts here are good for any software development effort, including Revolution-based. Holding on to old models like deep file system interaction really is a form of admitting defeat.

Loading mentions Retweet
Filed under  //   apps   feel   iPad   lookandfeel   revolution   UI  
Posted by Jerry Daniels 

Comments [3]

Weird copy and paste from Rev Dictionary

Loading mentions Retweet
Filed under  //   copy   dictionary   paste   revolution  
Posted by Jerry Daniels 

Comments [0]

Revolution dev platform and ePublishing

I've often felt that an eReader built in Revolution would be a natural. If we could make Revolution readers for Blackberry and iPhone, we'd be all set. The road for doing all this is being paved as I type by Amazon, Barnes & Noble and now Hearst.

Here is Heart's ePublishing device and model:

Hearst is also offering a dedicated reader, the Skiff:

     
Click here to download:
Revolution_dev_platform_and_eP.zip (1189 KB)

Here's their rap on it:

The Skiff Reader, the first e-reader to integrate the upcoming Skiff Service, is a state-of-the-art device that is simple and easy-to-use. Our innovations include:
  • Largest e-paper display › More viewing area for a richer reading experience.
  • Thinnest e-reading device › Remarkably sleek. Easy to hold, use and carry.
  • Most durable e-reader › First-of-its-kind metal-foil display (eliminating the fragility of glass). A magnesium housing. An incredibly sturdy device.
  • Highest display resolution › Four times as many pixels as most e-book readers, for more immersive reading.
  • Full touch screen › For intuitive content selection and navigation. Instant page turns with the swipe of a finger.
  • Extraordinary battery life › Read for a week between charges.

Loading mentions Retweet
Filed under  //   development   digital magazine   eink   epublishing   ereader   hearst   revolution   skiff  
Posted by Jerry Daniels 

Comments [0]

Kevin Miller Moonlights in band

The glasses didn't fool me.

Loading mentions Retweet
Filed under  //   ceo   humor   kevin   miller   revolution   runrev  
Posted by Jerry Daniels 

Comments [0]

Need to run Classic under Snow Leopard?

If it's HyperCard you're trying to run, Revolution can do that—no Classic needed!

I posted a comment to the article where I point out "Revolution can do that!" without resorting to SheepShaver/Classic.

Loading mentions Retweet
Filed under  //   hypercard   mac classic   revolution   sheepshaver  
Posted by Jerry Daniels 

Comments [0]

The Revolution will be programmed, Part 1

When someone describes someone else as "long in the tooth" you know what they mean: That the target of the soubriquet is getting on in years.

OK, but do you know where that phrase comes from? The answer is from the horse world: Horses' teeth grow throughout their lives and, despite getting worn down by chewing hay and such, horses show progressively more enamel as they age. Thus, you can roughly tell the age of a horse from how "long in the tooth" it is. Now you know.

Anyway, should you also be "long in the tooth" you'll remember a programming system called "HyperCard."

Created for Apple Computer and released in 1987, HyperCard was the first "hypermedia" system, a term coined for a hyperlinked collection of various forms of media (text, video, audio and so on) that creates a non-linear multimedia presentation; what are essentially complex, engaging rat holes of content that can suck you into their yawning limbo for hours on end. In other words, exactly what the Web has become.

HyperCard also had its own language called HyperTalk, which eventually evolved into Apple's AppleScript.

HyperTalk had an almost English-like, chatty quality described in that classic of hacker literature, the Jargon File under the heading "candygrammar."

The Jargon File explains candygrammar as "a programming-language grammar that is mostly syntactic sugar … The usual intent of such designs is that they be as English-like as possible, on the theory that they will then be easier for unskilled people to program."

The File continues: "This intention comes to grief on the reality that syntax isn't what makes programming hard; it's the mental effort and organization required to specify an algorithm precisely that costs. Thus the invariable result is that 'candygrammar' languages are just as difficult to program in as terser ones, and far more painful for the experienced hacker."

We'll revisit the candygrammar issue a little later, but for now here's an example of HyperTalk programming from the  Wikipedia entry to give you a flavor of the language:

on mouseUp
    put "100,100" into pos
    repeat with x = 1 to the number of card buttons
        set the location of card button x to pos
        add 15 to item 1 of pos
    end repeat
end mouseUp

Pretty chatty, eh? Anyway, HyperCard was a groundbreaking concept and existed as a product for sale until 2004, the year it was officially terminated (it had not been updated for some years).

The importance of HyperCard in computer and Internet history cannot be underestimated: For example, Ward Cunningham, considered to be the father of Wiki, contends that a HyperCard stack he wrote in the late 1980s was the genesis of the whole Wiki concept.

I don't have the space (or patience) to delve into the rest of the labyrinthine history of HyperCard and HyperTalk here but, suffice it to say, pretty much everything to do with both was either groundbreaking or just plain cool and, thus, was a legend born.

A derivative of HyperCard was a product called MetaCard, which has been described as "a cross-platform, commercial GUI toolkit."

Metacard was acquired by a Scottish company, Runtime Revolution, in 2003, and they re-engineered it to become the product that we'll be taking a close look at in the next column or two: Runtime Revolution.

Revolution is a complete rapid application development system that includes a graphical IDE and debugger with cross-platform support for Windows, OS X and Linux.

At the heart of Revolution is a HyperTalk-like language that is object-oriented and event driven. This means that Revolution applications are driven by events such as "key down" or "mouse over" that are associated with objects such as buttons and text fields. System events are also generated by, for example, the start of a Revolution application or a timer.

These events are captured by a hierarchy of event handlers (I'll explain the hierarchy in a subsequent piece), which contain scripts. These handler scripts can do all of the normal things programs do (such as access files and databases and write to the display), but they can also handle event data (such as the result of a key press) and can, in turn, generate their own events.

By now you are probably all kinds of excited by the idea of Revolution but you'll have to wait for next week's Gearhead for the next exciting episode as I've run out of space.

A great part 1 in a 3-part series of articles on Revolution!

Loading mentions Retweet
Filed under  //   article   networkworld   revolution  
Posted by Jerry Daniels 

Comments [0]

The Revolution will be programmed, Part II

Last week here in Gearhead I started to discuss a fascinating and powerful programming system called Revolution.

I explained that Revolution is event driven and every event generates a message: For example, starting a Revolution program (which is an event) generates a series of start-up messages, while clicking on an object (also an event) such as a button generates a series of mouse messages (for example, mouseOver, mouseDown, mouseDoubleDown, mouseStilldown, mouseWithin and mouseUp). There are around 200 messages generated by events and Revolution scripts can also generate their own messages.

Before I explain how these messages are handled I need to explain how a Revolution application is organized. A Revolution application is contained in a file and consists of one or more "stacks" (a main stack and optional substacks), each stack containing one or more "cards". Using Revolution's graphical, integrated development environment (IDE) you can create stacks and cards and add objects to them using drag and drop.

Now, everything in a Revolution application is an object including the stacks and cards. In addition, there are also objects users will interact with (also called "controls") such as buttons, labels fields, text fields, sliders, combo boxes and so on. These get positioned on the graphical layout of cards and can be grouped, making yet another object.

All objects have properties which you can browse and modify using the IDE's property inspector and, beyond the visual attributes (for example, the existence, size, width and color of the borders of a text field) and the control properties of objects (such as whether a text field is enabled and visible) there are scripts that are contained in objects.

Scripts consist of handlers of which there are four types. Message handlers receive messages while function handlers return values when called by scripts. The other two types are special ones that are triggered by requests to get or set object properties.

Scripts can also use functions stored in libraries that add features such as printing, Internet services and manipulate XML data.

So, here's the Revolution script for a simple pulldown menu object (Revolution considers these to be a type of button) called "mainMenu". This menu object displays three options, "Do This", "Do That", and "Status":

on menuPick pItemName switch pItemName case "Do This" <some code> break case "Do That" <some more code> break case "Status" <yet more code> break end switch end menuPick

When the user changes the menu selection a message is generated that consists of "menuPick" and the selected item's text. It is left for the reader to figure out how the switch construct works, but I doubt you'll break into a sweat.

Now, if we wanted to add a button somewhere in the user interface to also show the status we could place a button object to the card with the following script:

  on mouseUp
      send "menuPick Status" to button "mainMenu"
  end mouseUp

You can probably guess what is going on by reading the script. But what if there was no "mainMenu" button object? Well, then the message would be sent down the message path.

This path really starts with the "frontscript" where handlers can be placed to trap system or user generated messages before any other handlers further down the path, including those in the object's script, can do anything with the messages.

If there's no handler in the frontscript or the object's script and the object is a member of a group then the message is passed to the group's script. If there's still no handler the message gets passed to the script of the card the object is on, then to the "background" script (backgrounds are groups for cards), then to the stack the object is on, then to the main stack if the object is on a substack, then to the "backscript" (a catchall step on the path and the group of all stacks). If there's still no handler the message is passed to the Revolution engine, which will then execute the default action for the message and the object.

For example, if a key is pressed in a text field object, a "keyDown" message is generated, which includes the key that was pressed. Obviously a handler could be placed anywhere in the path to trap and remove or modify keyboard data as it is entered, but if there isn't one then the Revolution engine will get the message and do the default action for that object, to wit, update the text field display.

In other words, using Revolution you can handle system and user events at any level of detail providing as fine-grained control over the user interface and application behavior as you need.

Next week, into the "candygrammar" of Revolution.

A great part 2 in a 3-part series of articles on Revolution!

Loading mentions Retweet
Filed under  //   article   networkworld   revolution  
Posted by Jerry Daniels 

Comments [0]

Revolution in the news!

RunRev aims to boost programming sector

Sep 18 2009 Scott Mcculloch

NASA, Apple and Adobe use the company's new software

A scottish company is aiming to revolutionise the computer programming industry when it launches its new plain language software on the internet.

RunRev, based in Edinburgh, will offer a free web version of its revTalk and revMedia 4.0 software package in November.

The coding language is billed as the simplest in the world and compatible across multiple platforms and interfaces.

Nasa currently uses RunRev's desktop version, Revolution, as a software development tool to control satellites from its Mission Control facility in Texas.

Industry giants such as Motorola, KLM, Siemens, Apple and Adobe also use Revolution to create their own programmes to collate and manage millions of lines of coding information.

Kevin Miller, founder of RunRev, believes the web launch will see the business more than double in size.

He said: "We believe revMedia 4.0 will revolutionise web 2.0 application development as it is currently the world's simplest coding software in the plainest programming language available.

"We have historically sold the technology as a desktop development tool and we're now offering the same technology in a web language version with rev4.

"There are an awful lot of people out there I would describe as hobbyist content experts who don't have programming experience to write their own web application, but now they can. Rev4 is compatible with both servers and desktop applications running on Windows, Mac and Linux, all popular web browsers and uses just one language, which opens up development to just about anyone."

Miller started RunRev in 1999 from a high school hobby idea and began selling the first version of the software in 2001.

The business now has the backing of two of the biggest names in the computing industry.

Mike Markkula, former chairman of Apple, and Robert Cailliau, the co-developer of the World Wide Web, are both shareholders and helped drive the development of revMedia4.0.

Markkula stepped in with funding for RunRev's 2003 acquisition of US company MetaCard Corp, which had partnered the Scottish company in its first version of the Revolution development tool.

The acquisition allowed RunRev to modify and improve the software for updated versions of Revolution.

Miller believes revenues will exceed £1m illion for the first time this year. He said: "We've seen very steady growth in the last three years, up from £400,000 three years ago to around £1m for this year, but the web launch of rev4 will really ramp up our growth.

"Although the web version is free, we will create revenue through add-ons, training programmes and bespoke development packages for business. Mike Markkula and Robert Cailliau have been advising us through the process on a regular basis, and are very excited by the launch of this product."

Cailliau said: "I use revTalk for all my coding needs, and know it goes far beyond programming 'for the rest of us'.

"Professionals will appreciate the speed with which they can build sophisticated solutions."

Loading mentions Retweet
Filed under  //   coverage   news   revolution  
Posted by Jerry Daniels 

Comments [1]