hikaru.i.blog

is-ebiz o0a

Chapter 15 October 30, 2008

Filed under: Getting Real — hikaru011 @ 5:13 am
Tags: ,

To summarize it all up, this chapter talks about a few more steps before launching your
application. The first and second link talks about pre-launching the application. Getting Real
tells us readers that we should have a One-Month TuneUp before launching your application. You
have to test your application in order to tell whether the application is up and running.
With this kind of pre-launch, at least you still have time to may minor changes before the grand launch
starts.

The second link talks about not making “beta” an excuse. This link focuses on the word
imperfection. Getting Real tells us that we shouldn’t be wasting our time perfecting our application,
because it will never happen. There are no such thing as a perfect application. We cannot satisfy
every people. Some may think that this looks good with your application, others may say that it doesn’t.
Perfect Applications is a fantasy.

As I said in awhile ago, you cannot please everyone. There will come a time wherein
bad comments will arrive. You just have to “ride the storm”. Do not let them get to you. Do not ever
let them bring you down but use them as a motivation to keep you going. To help you make a better
application.

The next link talks about knowing who your competitors are. You have to know them too so that,
you too may get some tips which will help you with your application. I am not saying that you will
get his/her idea. I am just saying that you may learn from your competitors. To learn from them,
Getting Real suggests that you, as an application maker, should indulge yourself with other applications
which may help you track your competitors.

Lastly, keep an open mind!:) With this kind of mindset, you are not just focusing yourself to this kind
of system. At least, when new trends show up, you are aware of it.

Advertisements
 

Chapter 14 October 29, 2008

Filed under: Getting Real — hikaru011 @ 10:25 am
Tags: ,

This chapter basically tells us on what way we should build our product and how to control it after release. In the first part, feel the pain, it says there that when building something, you as a member of the team, should be aware on what is really happening around. When you are a programmer, it is also necessary that you have knowledge about the design of the product, who is your customers, what is the scope of your product, etc. As a programmer, your job does not end on coding alone. You should also know how to deal with the clients and other stuff that your group does. In dealing with your customers, you should be polite. Releasing the product is not the end of your project life cycle. You also need to support the users or your clients. You should guide them properly on the basics like how to use or run the system. Manuals are often comes hand in hand with any product that we purchase. It is where we can read on how to use what we bought. In this chapter, it is said that try building a zero manual product. It means that build a product that is so simple and user friendly so that customer can easily get used to it. But I think when you build a product that has no manual; you should open your lines for customers’ tons of questions. You don’t need to please them just be honest and just answer up straight. For example, you experiencing some technical problems, you should inform your customers right ahead before they start to panic and believe me it will cause your company a lot of troubles and worries. But when you think that it is more work loaded when you set up a huge technical support center, you can just open up a forum online. There a customer can post his own reaction over the product and can also advise other customer.

 

Chapter 13 October 19, 2008

Filed under: Getting Real — hikaru011 @ 10:14 am
Tags: ,

Basically, this chapter tells us application builders, to formally and beautifully, tell
the people about your application. In order to do so, Getting Real suggests that we should
go from a teaser, to a preview then launch. Hollywood style! With this kind of style, it
will attract people at the same time, you will know if your application clicked or not. At
least, you haven’t actually released your application yet. Instead of releasing it without
knowing if it will click or not. Like what Getting Real said: “If an app launches in a forest
and there’s no one there to use it, does it make a noise? The point here is that if you
launch your app without any pre-hype, people aren’t going to know about it.ut any pre-hype,
people aren’t going to know about it.”

You should also need a powerful promo site in order for the people to know what your application
can do. Based on Getting Real, you need the following in order to have a powerful promo site.
The following are:

*  Overview: Explain your app and its benefits.
* Tour: Guide people through various features.
* Screen captures and videos: Show people what the app actually looks like and how to use it.
* Manifesto: Explain the philosophy and ideas behind it.
* Case Studies: Provide real life examples that show what’s possible.
* Buzz: Testimonial quotes from customers, reviews, press, etc.
* Forum: Offer a place for members of the community to help one another.
* Pricing & Sign-up: Get people into your app as quickly as possible.
* Weblog: Blogs keep your site fresh with news, tips, etc.

After doing all that, you now need to put up a site wherein people can enter their email
addresses if they are interested with the application. With that kind of foundation, you can
go rolling anytime. You can also put up a site where people can learn on how you came up with
the application.

Last but not the least, give your application a name wherein it will forever be stuck on
people’s minds. It should be a catchy one and easy to remember. Getting Real suggests that
it should’nt be too descriptive. The shorter, the catchier, the more memorable, THE BETTER!:)

 

Chapter 12 October 13, 2008

Filed under: Getting Real — hikaru011 @ 11:36 am
Tags: ,

Free Sample

Basically in order to attract customers, you should entice them. An example given in the reading is apple itunes. Itunes is free software that you can download in the internet. In this strategy, Apple also commercializes or advertises their product, I pod.

Easy On, Easy Off

From signing in and signing out from a site, it should be easy. Most people prefer fast and the simplest app.

Exit with Ease

Don’t hold users against their will. If they want to leave, let them pick up with all of the content they created while they were on your site and leave…for free… You have to let the barn door open and focus on keeping your customers fed, so they want to come back, instead of coming back because they’re stuck

Silly Rabbits, Tricks are for kids

Avoid long-term contracts, sign-up fees, etc

Don’t try to find “tricky” ways to get more cash. Earn it.

A Softer Bullet

When you are about to deliver bad news, make it as painless as possible by making plenty of advance notices.

 

Chapter 11 October 8, 2008

Filed under: Getting Real — hikaru011 @ 12:33 pm
Tags: ,

There’s Nothing Functional about a Functional Spec

Spec documentation is a blueprint or outline. A functional spec is said that it usually wind up having nothing to do with the finish product. They are not the real thing that you’ll be working on. It is just a piece of paper so there’s no need to spend so much time and effort making this.

Don’t do Dead Documents

Build, don’t write. Do not waste time on making documents that are unnecessary. It is just a waste of time.

No One’s Going to Read It

I can’t even count how many multi-page product specifications or business requirement documents that have languished, unread, gathering dust nearby my dev team while we coded away, discussing problems, asking questions and user testing as we went. I’ve even worked with developers who’ve spent hours writing long, descriptive emails or coding standards documents that also went unread.

Webapps don’t move forward with copious documentation. Software development is a constantly shifting, iterative process that involves interaction, snap decisions, and impossible-to-predict issues that crop up along the way. None of this can or should be captured on paper.

Don’t waste your time typing up that long visionary tome; no one’s going to read it. Take consolation in the fact that if you give your product enough room to grow itself, in the end it won’t resemble anything you wrote about anyway.

Tell me a quick story

Think strategy, not tactics. When you are about to write new features or concept of a product, it is better to write a brief story about it. Avoid using technical terms and making it as an outlined document. Use common terms that anyone can understand and appreciate.

Use Real Words

Lorem Ipsum Garbage

By not having the imagination to imagine what the content “might” be, a design consideration is lost. Meaning becomes obfuscated because “it’s just text”, understandability gets compromised because nobody realized that this text stuff was actually meant to be read. Opportunities get lost because the lorem ipsum garbage that you used instead of real content didn’t suggest opportunities. The text then gets made really small, because, it’s not meant to be used, we might as well create loads of that lovely white space.

Personify your product

Think of your product as a person. Keep these traits as the product is built.

 

Chapter 10

Filed under: Getting Real — hikaru011 @ 12:14 pm
Tags: ,

Less Software

“.. Keep your code as simple as possible.” When you keep on revising, the more complex and complicated your product will be. Remember that you have a scope and in that scope are the limitations and main purpose of your product.

  • Less software is easier to manage.
  • Less software reduces your codebase and that means
  • less maintenance busywork (and a happier staff).
  • Less software lowers your cost of change so you can adapt quickly. You can change your mind

without having to change boatloads of code.

  • Less software results in fewer bugs.
  • Less software means less support.

Optimize for happiness

It is important that when you work, people should be comfortable. When you use a language, you must think if your people can really work on it. If the workers are comfortable, they can write simply and readable codes. They can execute it properly and surely they can really do their job well.

Code Speaks

Listen up

“Don’t worry about design, if you listen to your code a good design will appear…Listen to the technical people. If they are complaining about the difficulty of making changes, then take such complaints seriously and give them time to fix things.”

Open Doors

“Don’t try to lock-in your customers. Let them get their information when they want it and how they want it.:

 

Chapter 9 October 1, 2008

Filed under: Getting Real — hikaru011 @ 9:23 am
Tags: ,

Interface First

Design your interface first. Basically start with what people are going to see and use. Designing it does not necessarily coding and doing it in the computer. You can use paper and pencil to come up with a design that people would love to see.

Epicenter Design

Start with what is really essential. In the example from the reading, when making a blog post, start working with the blog itself rather than doing the sidebars, headers, etc. Do the essentials first before the extras.

The three state solution

  • Regular
    The screen people see when everything’s working fine and your app is flush with data.
  • Blank
    The screen people see when using the app for the first time, before data is entered.
  • Error
    The screen people see when something goes wrong.

The Blank Slate

Here are some reasons why you need to include a blank slate:

  • Use it as an opportunity to insert quick tutorials and help blurbs.
  • Give a sample screenshot of the page populated with data so people know what to expect (and why they should stick around).
  • Explain how to get started, what the screen will eventually look like, etc.
  • Answer key questions that first-time viewers will ask: What is this page? What do I do now? How will this screen look once it’s full?
  • Set expectations and help reduce frustration, intimidation, and overall confusion.

Get Defensive

When you launch something, surely it goes under several testing. But the fact is customers can still encounter problems. The defensive design is somewhat compared to defensive driving. Defensive driving is when you keep any eye for any problems you might encounter while driving. Defensive design is like keeping an eye for any problem you can encounter that can cause visitors confusion and frustration.

Remember: Your app may work great 90% of the time. But if you abandon customers in their time of need, they’re unlikely to forget it.

Copywriting is Interface design

Good writing is good design. When you design, basically designs are not just animation, features, effects, pictures, etc. Letters are automatically involved. Some of the developers think that if they use jargon or highfaluting words, people may tend to think that they are unreachable. People can get confuse. Try using language that all of us can understand so that confusion won’t take place.

One interface

Most of the companies develop an admin screen, which is use for updating, edit, delete, etc. and the user screen, the one that people can visit. Having two different screens can encounter several problems like tax, etc. If you only have one screen that can be use, it is much better because the fewer screens you have to worry about, the better they’ll turn out.