Summer Entrepreneurial Experiences

Author Archive

Week 7

Sunday, July 15, 2012 8:17 am

…And we’re back.

Our first round of public testing began over the past week. Before I continue, I should explain what exactly the testing process is like, or at least, was like in our experiences the past two weeks. A lot of friends and colleagues outside of computer science that I’ve spoken with have this idea of what software testing is like: namely, that the developer (myself, in this instance) stands over the tester, gives them the app and a brief introduction on how to use it, and answers question and actively takes feedback throughout the process. Now, I can’t speak for other developers and their testing practices, but the preceding description only bears small similarities to how we conducted our tests. Perhaps the biggest difference is that I myself wasn’t actually present at the “testing”. Instead, I was given feedback indirectly. This provided more useful information than I might have received otherwise. It captured an environment of non-interference; in other words, what the testers experienced would likely be what a customer would experience were they to buy and use the app as-is from the App Store.

And the feedback was, ultimately, pretty bad. When I say “bad”, I don’t mean that the testers hated the app’s concept or that it was unusable. But, there were some pretty glaring bugs and errors, and suggestions for some features that I had never thought of, but now seem very intuitive. That’s not the difficult part of testing feedback, however. Bugs or obvious feature suggestions are largely objective judgments. For example, if a bug exists in the programming, a bug exists; it’s not a matter of opinion. If something like a “copy” feature is suggested, it’s not necessarily objective, but nevertheless fairly easy, to evaluate the costs and benefits of spending time developing that feature. The challenging part of interpreting testing feedback is when the advice isn’t necessarily good advice. This is not to say that the feedback we received was of this nature; to the contrary, a lot of the suggested fixes and feature additions will be going in to the next version. However, as the app moves closer to a finished product and testers begin to offer more and more specific feedback, it’ll be necessary to start making judgment calls about what advice to follow, and what advice to ignore.Making those kinds of judgments about feedback are inevitable. There’s simply not enough time, resources, or willpower to implement every feature suggestion. Sometimes, a feature suggestion may even be contrary to what the app’s design is. Other times, implementing a feature may simply require too much reworking of old design (remember a few posts ago when I said good base design was crucial? Here’s an example…).

Eventually, I want to be part of a testing session for Lesson Sculptor as an observer, and I believe there are plans for that currently in the works. There’s something to be said for observing a tester’s interactions with the app in a first-person environment.

Until next time.

Week 6: Progress

Tuesday, July 3, 2012 9:34 am

Hello again.

Two big pieces of news to report on this week.

First, something different. I’ve received word that the LLC I’m working for will not only be releasing Lesson Sculptor, but also has plans to launch another application that is much further along in its development than Lesson Sculptor is. While I can’t reveal too many details about it, as nothing has been “confirmed” yet, the game aims to teach motor skills and object recognition to children. I know that doesn’t sound like much of a preview, but rest assured, once I can be sure that all the formalities are completed, I’ll be going in to much more detail.

Second, I’m proud to announce that Lesson Sculptor finally has a working version. In other words, all of its basic functionality is finished, we’re now in the phase of perfecting the application, adding new features, and testing it publicly, all in the hopes of having a version ready for App Store submission by the end of the summer. There were two big hurdles we overcame this week in terms of bug fixes. It’s hard to describe them without going in to technical details, but I hope it suffices as an explanation that both were large brick walls in the app’s development.

So, what’s next? Well, I sort of previewed the next steps back in Week 2. While I don’t have a exact timeframe, we’re going to have to start thinking a lot more seriously about a legitimate marketing strategy, rather than just brainstorming and tossing around ideas. I imagine that’ll be quite the adventure, and will most likely me the subject of Week 7.

Until next time.

Week 4 and 5 – Coding, coding, coding…

Tuesday, June 26, 2012 3:03 am

Hello again!

The past two weeks have been something of a dull period in our application’s development. Rather than trying our hand at some new aspect of the business side of software development, we instead have been spending the past two weeks more or less implementing the designs we finalized in the first few weeks of the project, which has involved a lot of coding, in-house testing, and more coding. For those of you who have little experience with how software development works (which is not to say I am some guru myself), to summarize the process: we’ve spent a lot of time the past two weeks sitting in front of a computer for hours on end, doing the equivalent of editing a large word paper. The only difference is that whereas a spelling error in a document may be a minor inconvenience, to make the equivalent of a spelling error places a halt on all progress in coding. Sometimes, these errors are largely insignificant and easily caught and/or fixed by the equivalent of a spell-checker, to extend the paper analogy. Others, they can go largely unnoticed, and while an error like the innocent misspelling of a word in a document is harmless, in a program, it can cause the program to run, but behave erratically – one of the must frustrating types of errors to fix.

Consequently, this is where good designs are critical. Good designs make for easier program writing because they simplify the coding necessary to implement a functionality, while also making it easy to maintain. An analogy that explains this, albeit somewhat stretching to fit this example, is solving a probability problem like the chance of a coin coming up heads. It’s entirely possible to run 100 tests of the problem, average the results, and find an answer. But doing so is tedious and prone to error (what if a test is skewed, or ananomaly occurs where tails shows up 70 times?). Instead, it is much easier to simply apply a probability principle, in this case, 1 desired outcome / 2 possible outcomes means a 50% chance. All designs that solve a problem are not created equal, and half the struggle in the application’s development is making sure we get as strong and flexible design as we can.

Until next week.

Week 3: A Grand Design

Wednesday, June 13, 2012 9:31 pm

A bit of a late post this week, have been caught up in a lot of work related to our application. I nearly forgot to give an update through the blog, so I hope you can forgive my tardiness.

This past week was fairly slow on a lot of fronts. Since most kids are out for the summer, a difficulty we have encountered is locating suitable test groups for the application. While we can certainly present the application to teachers, the application itself does not really get tested unless there are students who can use the mini-apps the teachers make. One possible alternative we are exploring is families. Ideally, we would present the application to a parent of a younger child (a special needs child preferably, but any child would also work just fine given what we want to test at this point during the app’s development), and then see how the child would interact with their parent’s creation. That way, we could observe how intuitive the application is to both the creators of lessons (parents/teachers) and users of those lessons (students/children). We have a couple of families lined up at the moment, and can hopefully procure several more.

I received several comments on last weeks post about our marketing tactics (or lack thereof). First, I wanted to thank all of those who posted. I approach the concept of marketing with the full realization that I am several steps below a novice in terms of skill level or knowledge of advertising; any advice those of you in business have is welcomed with a wide open mind. Secondly, we’ve taken into account most of the suggestions. Some of the past week was spent compiling a list of things competing products do better than our application, for example. Other pieces of advice are currently the subject of some internal debate. An example is the pricing of the application-some have posted that we shouldn’t try to compete on a low price alone or as a main strategy. Other colleagues who have marketing knowledge that I have talked to have confirmed that advice as sound. Even then, however, it seems difficult to justify an App Store product that sells for $200, at least intuitively. Another less economic and more altruistic concern about charging a higher price is simply getting the application to be used in the educational environment. The primary purpose of our LLC to be created, I’m told, is more so to provide tools for teachers, rather than being a strict software development business. Ultimately, we’ve decided to defer these discussions until an actual launch version of the app is ready, from which we can make more accurate assessments about how much we think the app could be reasonable bought for.

The last piece of work we managed to accomplish is wrapping up the larger design work for the application. Now, some of you may be wondering how it’s possible we just finished the design work while we’re already talking about testing. The idea behind testing the application, even if it’s not completely finished, is to receive feedback during the development process that guides the application’s creation, rather than having to retroactively make those changes after its first complete testing version, which will allow us to make grander changes to the app as necessary without the expensive cost of having to re-write large portions of the app once completed. This software development method, which focuses on iterative development of components of the application and the subsequent testing/refinement of them is a simplified version of “agile software development”. I could, and probably will, write an entire post about agile software development and how Lesson Sculptor’s creation utilized the development method. But, that’s for a much, much later day.

Week 2: Competing with other Apps/Services

Monday, June 4, 2012 3:40 am

Well, the initial testing of the product has been delayed due to logistical reasons. Whereas I had hoped to be writing a little about the outcomes of that first round of testing, instead I have a surprise topic that I hadn’t planned to write about/research until much later.This week, I got one of my first experiences with marketing. Being a Computer Science major, where the majority of my projects/learning experiences have been confined to command line programs or projects to teach a particular concept, the idea of competition with other projects was a largely foreign concept to me. I was instructed to gather research about other apps on the App Store that shared a similar purpose or functionality to Lesson Sculptor, and determine the differences between their product(s) and ours.

I already knew that there were millions of apps on the App Store. What I didn’t know was what exactly it felt like to search through all of them trying to find a particular application that had the most similarities with Lesson Sculptor. I quickly discovered that while cursory searches may reveal some apps that much a description, it doesn’t reveal all of them, and combing through the results can be burdensome (looking back, this seems obvious, but at the time it was surprise). This meant that I wasn’t really getting the most information from my searches. After all, if an app similar to Lesson Sculptor doesn’t show up initially, is that a sign of trouble (i.e., other apps have tried a similar concept, but failed, and were thus pulled from the store by their developers)?

I discovered that the main reason for my research being less fruitful than I had hoped for was largely attributable to searching in the wrong place. As it turns out, several services that offer the same terminal functionality as Lesson Sculptor (that is to say, give the capability for a teacher with no coding knowledge to build their own app) already exist. I was able to find several firms and websites that offered iPhone developer connection services. The services’ design works as follows: someone (in this case, a teacher) contacts the firm with an app idea and the specific functionality they want the app to have. The firm then contacts interested developers, and essentially manages the project until its release on the App Store. Thus, the teacher is able to “build” their own apps.

The question then, that we have to answer is simple: What does Lesson Sculptor do that these services don’t? The answers seemed pretty obvious:

1) Lesson Sculptor gives teachers more direct control over their lessons, rather than indirectly working with a developer/firm.

2) Lesson Sculptor works quicker than these services. Teachers have to constantly recontact the firm if they want a new app for a lesson. While Lesson Sculptor doesn’t create a full-fledged app like these services do, it often won’t need to for lessons)

3) Lesson Sculptor is cheaper. A lot of these services charge up in the hundreds; while we don’t have a final price figure for Lesson Sculptor (the app isn’t even done with its initial development yet), this could be a selling point for its launch.

Our next step is to formulate these advantages into a coherent marketing strategy. While the final strategy will likely occur much further down the road, we plan to contact some Wake Forest professors with marketing expertise to get their advice on moving forward.

Until next week.


Week 1: Hello, World!

Friday, May 25, 2012 8:11 pm

Lesson Sculptor is an iPad application that aims to empower teachers of early education students of all needs with the capability to create their own mini-applications tailored for the specific needs of their classrooms. Many applications, or “apps”, exist on Apple’s App Store with the express purpose to educate these exact target audiences. However, all of these applications have the inherent limitation of limited functionality; in other words, they can only do what they are programmed to do, and what an app is programmed to do may work for one child, but could be inadequate for another with disabilities. For example, an app that aims to teach basic sentence construction may be inadequate for an autistic child that is offset by even the most seemingly insignificant of features, like a congratulatory message that plays loud noises. However, an application that appeals to these limitations may be too simplistic for a child without those disabilities, or in many cases simply inappropriate.

Even in the instance where an application or technology is ideal for a particular child, there still exists in several cases a divide between what technologies or programs that parents and teachers can share. For example, a speech therapist or teacher may utilize a special technology as a learning aid to a student with special needs. Frequently, these technologies are expensive, limited in their functionality, and in many cases are hard to acquire for a parent from the specialized company that produces them. Teachers can also face this problem when a parent utilizes a technology that the teacher can not acquire due to school budgetary allocations. The end result is disjointed communication between parents of a child and teachers of that child.

With the iOS family of devices (iPhone, iPod, and iPad) seeing more use in the realm of education to digitize things like textbooks, the time seems ripe to make another advancement in the synergy between education in the classroom and interaction at home, and to digitize functionalities that are currently being implemented on obsolete platforms.

Lesson Sculptor, to be released under an LLC established later in the summer, will provide teachers and parents with a friendly interface to construct mini-apps of their own, called “Lessons”, that will enable the maximum usefulness and applicability to a specific child. Rather than invest hundred and thousands of dollars into technologies to accomplish several functionalities, Lesson Sculptor will grant the capability to replicate those functionalities for a fraction of the price, on a common platform that is seeing exponentially increasing use among the general public.

To that end, the past week was spent outlining goals to meet for the App’s next phase of development. A grand deal of work has been done due to the work of myself and my colleagues, Brian Lucas and Michael Nipper, in a class taken this past semester. However, the app is far from ready to publish, but we aim to have closed testing of the application begin by next week. A large portion of the past week was also spent towards finishing the implementation of the last remaining core features of the product. In-house testing began soon after, which revealed the presence of several bugs that have been tagged for fixing.

It’s always difficult to anticipate what exactly testing will reveal is flawed about the product-it could be (and certainly will be) bugs in the programming that hinder the app, but could be as significant as discovering the concept behind the app is not as intuitive as we initially believed. Either way, the next week will be an exciting time in the app’s development, as the results of our first round of testing will in many ways confirm or invalidate several existing design decisions, in addition to providing guidance on further development of Lesson Sculptor.

Until next week!


Alexander Adcock (7)
Gracious Addai (3)
Susie Alexander (6)
Assel Aljaied (10)
Megan Archey (7)
Kenneth Bailey (6)
Marco Banfi (3)
Johanna Beach (8)
Jessica Blackburn (8)
Tiffany Blackburn (9)
Meredith Bragg (9)
Quentin Brillantes (8)
Samuel Buchanan (5)
Robbie Bynum (1)
Cailey Forstall (9)
Cameron Steitz (5)
Cecelia Carchedi (3)
Carl Turner (2)
Adelina Cato (5)
Kristi Chan (7)
Brittani Chavious (12)
Avinav Chopra (1)
Hannah Clark (8)
Kathryn Covino (8)
Sarah Crosier (8)
Keshav Daga (8)
Jennifer Daye (7)
Mike Dempsey (8)
Eva Dickinson (2)
Will Dietsche (8)
Catherine Douglas (8)
Zanny Dow (8)
Stephen Eason (8)
Elisa Burton (1)
Epiphany Espinosa (5)
Hannah Shows (8)
Nina Foster (5)
Hannah Gable (8)
Charlie Garner (8)
Kent Garrett (8)
Nicholas Gomez-Garcia (8)
Gracie Wiener (6)
Brooks Hall (7)
Meghan Hall (7)
Tim Han (1)
Adrienne Henderson (1)
Ryon Huddleston (7)
Adeolu Ilesanmi (8)
Nicole Irving (8)
Jessica (8)
Dalton Jones (8)
Kevin Wang (5)
Ty Kraniak (11)
Nick Ladd (15)
Elizabeth Lane (8)
Yuan-Chih Lee (8)
Kenneth Lowery (5)
Duncan MacDougall (6)
Lauren Martinez (7)
John McMurray (8)
Megan Miller (5)
Colt Mienke (1)
Brad Neal (9)
David O'Connor (9)
Olivia Wolff (3)
Kristen Plantz (8)
Lucy Rawson (7)
Cynthia Redwine (6)
Julia Reed (8)
Matt Roemer (8)
Melissa Ryon (3)
Eleanor Saffian (8)
Kayla Santos (8)
Maddie Saveliff (2)
Lisa Shaffer (8)
Ben Smith (10)
Christian Spake (8)
Ollie Spalding (8)
Alan Spencer (8)
Anna Tal (8)
Shelby Taylor (8)
Jake Teitelbaum (5)
Segen Tekle (1)
Katherine Thomas (8)
Tommy Lisiak (8)
Travis McCall (8)
Jawad Wahabzada (5)
Kurt Walker (4)
Kristen Watkins (2)
Arthur Willson (1)
Jonathan Williams (8)
Sathya Williams (1)
Katie Winokur (8)
Elaheh Ziglari (8)
Jenna Zimmerman (8)
ZSR (1)
May 2017
August 2016
July 2016
June 2016
August 2015
July 2015
June 2015
May 2015
April 2015
August 2014
July 2014
June 2014
May 2014
August 2013
July 2013
June 2013
May 2013
August 2012
July 2012
June 2012
May 2012
User Tools
Log in

Powered by, protected by Akismet. Blog with

Serving Humanity Through the Pursuit of Knowledge

Copyright © 2010 Wake Forest University ~ 1834 Wake Forest Road, Winston-Salem, NC ~ 336.758.5000