Frustrating in developing Corona app for clients.

General (non-technical) Off-Topic
#1

“Corona developer is not an official app developer.” That was what client thought.

I know it is not Corona’s fault, it can’t support every feature people want.

But it is really frustrating to work with this SDK in the really world.

Every time there is something that client wants but not supported by Corona SDK,

they are like… " so you are not a native developer, you should have told us."

No matter how much I explained there are limitations with this SDK but

it is also the most efficient way to develop multi-platform app.

Client always wants more.

As the developing progress, they might have new ideas that they wanted it so bad.

They felt treated if you suddenly tell them

“Sorry, I told you there are limitations, you can’t do everything with Corona SDK”

They got crazy! "What about all my money went to the development!!??

Do you mean they are all wasted and I have to hire another “native” developer???"

It is very easy for client to feel other “native” developer is better than Corona developer

simply because they might achieve features that Corona developer can’t.

Do you have same story? How do you deal with it?

Is Corona SDK only for personal project and hard to make money?

Please share your thought. 

#2

You mentioned “limitations.” I think it’s reasonable to be frustrated if you’re running up against limitations that Corona could easily remove and hasn’t. For instance, Facebook sharing on Android via the social plugin – for developers who pay a decent chunk of cash for Pro – is still broken. I pointed this out last November, and it has yet to be fixed:

http://forums.coronalabs.com/topic/52755-can-corona-enable-limited-facebook-sharing-on-android-via-nativeshowpopup/

 

It took years for support for iOS sharing (via action sheet) to be added a few weeks ago, but it still doesn’t work on iPads or with Instagram. Etc.

 

On the other hand, in defense of Corona, not all developers clearly explain to their clients in advance, in writing, what the costs and benefits of certain architectural and SDK approaches are. You haven’t given any specifics in your post.

#3

Thank you. I agreed there are some very small bugs took so long to be fixed.

The thing is most clients didn’t mention(or think of) their request at first place.

Take my previous project as an example.

It was a pet app for people to know more about their pets.

We’ve looked over the wireframes and made sure everything is doable with Corona SDK.

I also explained the benefit of using it (ex: it is a big save to convert it to Android version later.) and limitations (I can only guarantee to fulfill the listed features).

One month later, the client suddenly wanted to implement Google Analytics. (I am not sure for now, but it’s not supported at that time)

They got so angry to realize they need to pay enterprise account to be able to use native code to have this simple feature that

every other their friends’ apps have.

Yet I still don’t know how to deal with this situation. If I knew they want something Basic Corona not supported, I would definitely stop them at the beginning.

#4

That doesn’t seem like your fault. You can’t be blamed for an irrational client. Maybe in the future have an explicit list of what’s not supported in Corona SDK (Android Facebook sharing, iOS Instagram sharing, different formatting inside text blocks, overlays on native widgets like webviews, proper status bar transparency on Android, tableview variable-time deletion of rows, fast text on Windows Phone, etc.)

Though FYI Google Analytics has for the last year or so had an “app analytics” variant. I implemented an interface in Corona SDK last summer, and I’ve subsequently seen a public and free-to-use module mentioned on the forums with a link to download.

#5

Hi @fudesign,

Here is the link that @corona273 mentions, re: a 3rd-party module for implementing Google Analytics:

http://forums.coronalabs.com/topic/50536-release-google-analytics-module/

Brent

#6

Thank you, guys.

#7

I have also found myself in similar situations, and I agree that it can be very frustrating.

I always try to clearly state to clients that the app will be developed using CoronaSDK and the pros and cons. But as they say, the devil is in the details. Even with clients who specifically recruit a corona developer, they don’t usually know all the limitations or work arounds that might be needed in delivering the app.

Many of these clients also want to hire developers at a fixed rate, so if you’re not careful you can easily underestimate a job.  Need to use pinch-zoom gestures on a picture inside a scrollview. Sure, that should be doable. 20 hours later and you’re still trying to work out the kinks.

I mainly fault CoronaLabs with not delivering on the plugin marketplace. How many of these missing features that clients are looking for, could have satisfied with a plugin. 

#8

Interesting discussion

I understand what it means to deal with such clients, it’s not your fault but you can do a lot to solve this:

  • Discuss the app
  • Create mockups, wireframes (you mentioned it)
  • Create a list of functions regarding what you both planned - discussed
  • THEN create a mutual deal, it’s a mutual agreement, seal the deal

In spanish there is a name for that document, it’s called DERCAS, you can read the wiki and perhaps find an english name, or create your own for your company. The thing is to write things down and create a mutual agreement, and respect it. Yes I know some clients watch tv and then come back with new additions to what was already sealed, it’s up to both of you to deal with that, or increase the budget for the new request AND a penalization for the new request, that’s 2 increases for the same thing, diff acts. In my experience some clients are better off left alone.

I try not to discuss too much the technology with clients, some judge by what they know about it, ignoring it can be done with this and that. One must analyze the features knowing what each tool can do, sometimes letting the client know this info makes them believe they can choose on what you will work. After the initial discussion one can come back with budget and analysis… like two separate native apps, one cross platform app, iOS, Android, WP, etc, or perhaps just two, etc.

#9

@fudesign,

I hear what you’re saying and to some degree understand your frustration.  However, in my experience this is mostly a problem of:

  • Insufficient specification before the project starts - i.e. Clients tell you they want to do A, B, D, F.  Then later tell you, “Oh yeah, I want C and E features too.”.  However, C and E features are either hard or impossible to do without jumping into Enterprise.  This is partly on the contractor (you and I), but if you clearly state, “All features must be specified before we start the project.”, and they late announce features it is on them.
  • Feature Flip-Flopping - Similarly, you’ll run into clients that want to change features all the time and add new ‘ideas’.  These folks are hard to satisfy.  However, I always tell my clients.  “First, I want a spec up front.  Second, if you should change or add features later in development, be aware that these features may be non-feasible or very expensive to achieve.”

I generally review the entire project outline a client gives me and then do my best to point out trouble areas (features that may not be supported well or easily.)  I’ve learned over time to, ‘guess’ where clients minds are going before they go there, but I still get suprised too.

Best of luck to you.

PS - I totally agree w/ the prior poster regarding setting up a contract in advance and also about penalties for feature changes.  

PPS - My biggest problem is I try to be ‘flexible’ but it always ends up causing me grief.  You’ve got to be hard nosed with clients throughout the process if you want to stay sane, and in business.

#10

One thing that sucks: designers who are willing to promise anything to get the job, even if/when they eventually fail to deliver. They ruin it for everyone else because clients, once they hear from a prospective designer who says, “Sure, absolutely, I can do that! I can do anything you want!” they expect that from the other designers they’re interviewing/considering. 

Soooo, if you’re trying to get a job while being honest with the client and setting responsible boundaries up front, some clients just see that as inflexibility. 

It sucks. 

#11

You mentioned “limitations.” I think it’s reasonable to be frustrated if you’re running up against limitations that Corona could easily remove and hasn’t. For instance, Facebook sharing on Android via the social plugin – for developers who pay a decent chunk of cash for Pro – is still broken. I pointed this out last November, and it has yet to be fixed:

http://forums.coronalabs.com/topic/52755-can-corona-enable-limited-facebook-sharing-on-android-via-nativeshowpopup/

 

It took years for support for iOS sharing (via action sheet) to be added a few weeks ago, but it still doesn’t work on iPads or with Instagram. Etc.

 

On the other hand, in defense of Corona, not all developers clearly explain to their clients in advance, in writing, what the costs and benefits of certain architectural and SDK approaches are. You haven’t given any specifics in your post.

#12

Thank you. I agreed there are some very small bugs took so long to be fixed.

The thing is most clients didn’t mention(or think of) their request at first place.

Take my previous project as an example.

It was a pet app for people to know more about their pets.

We’ve looked over the wireframes and made sure everything is doable with Corona SDK.

I also explained the benefit of using it (ex: it is a big save to convert it to Android version later.) and limitations (I can only guarantee to fulfill the listed features).

One month later, the client suddenly wanted to implement Google Analytics. (I am not sure for now, but it’s not supported at that time)

They got so angry to realize they need to pay enterprise account to be able to use native code to have this simple feature that

every other their friends’ apps have.

Yet I still don’t know how to deal with this situation. If I knew they want something Basic Corona not supported, I would definitely stop them at the beginning.

#13

That doesn’t seem like your fault. You can’t be blamed for an irrational client. Maybe in the future have an explicit list of what’s not supported in Corona SDK (Android Facebook sharing, iOS Instagram sharing, different formatting inside text blocks, overlays on native widgets like webviews, proper status bar transparency on Android, tableview variable-time deletion of rows, fast text on Windows Phone, etc.)

Though FYI Google Analytics has for the last year or so had an “app analytics” variant. I implemented an interface in Corona SDK last summer, and I’ve subsequently seen a public and free-to-use module mentioned on the forums with a link to download.

#14

Hi @fudesign,

Here is the link that @corona273 mentions, re: a 3rd-party module for implementing Google Analytics:

http://forums.coronalabs.com/topic/50536-release-google-analytics-module/

Brent

#15

Thank you, guys.

#16

I have also found myself in similar situations, and I agree that it can be very frustrating.

I always try to clearly state to clients that the app will be developed using CoronaSDK and the pros and cons. But as they say, the devil is in the details. Even with clients who specifically recruit a corona developer, they don’t usually know all the limitations or work arounds that might be needed in delivering the app.

Many of these clients also want to hire developers at a fixed rate, so if you’re not careful you can easily underestimate a job.  Need to use pinch-zoom gestures on a picture inside a scrollview. Sure, that should be doable. 20 hours later and you’re still trying to work out the kinks.

I mainly fault CoronaLabs with not delivering on the plugin marketplace. How many of these missing features that clients are looking for, could have satisfied with a plugin. 

#17

Interesting discussion

I understand what it means to deal with such clients, it’s not your fault but you can do a lot to solve this:

  • Discuss the app
  • Create mockups, wireframes (you mentioned it)
  • Create a list of functions regarding what you both planned - discussed
  • THEN create a mutual deal, it’s a mutual agreement, seal the deal

In spanish there is a name for that document, it’s called DERCAS, you can read the wiki and perhaps find an english name, or create your own for your company. The thing is to write things down and create a mutual agreement, and respect it. Yes I know some clients watch tv and then come back with new additions to what was already sealed, it’s up to both of you to deal with that, or increase the budget for the new request AND a penalization for the new request, that’s 2 increases for the same thing, diff acts. In my experience some clients are better off left alone.

I try not to discuss too much the technology with clients, some judge by what they know about it, ignoring it can be done with this and that. One must analyze the features knowing what each tool can do, sometimes letting the client know this info makes them believe they can choose on what you will work. After the initial discussion one can come back with budget and analysis… like two separate native apps, one cross platform app, iOS, Android, WP, etc, or perhaps just two, etc.

#18

@fudesign,

I hear what you’re saying and to some degree understand your frustration.  However, in my experience this is mostly a problem of:

  • Insufficient specification before the project starts - i.e. Clients tell you they want to do A, B, D, F.  Then later tell you, “Oh yeah, I want C and E features too.”.  However, C and E features are either hard or impossible to do without jumping into Enterprise.  This is partly on the contractor (you and I), but if you clearly state, “All features must be specified before we start the project.”, and they late announce features it is on them.
  • Feature Flip-Flopping - Similarly, you’ll run into clients that want to change features all the time and add new ‘ideas’.  These folks are hard to satisfy.  However, I always tell my clients.  “First, I want a spec up front.  Second, if you should change or add features later in development, be aware that these features may be non-feasible or very expensive to achieve.”

I generally review the entire project outline a client gives me and then do my best to point out trouble areas (features that may not be supported well or easily.)  I’ve learned over time to, ‘guess’ where clients minds are going before they go there, but I still get suprised too.

Best of luck to you.

PS - I totally agree w/ the prior poster regarding setting up a contract in advance and also about penalties for feature changes.  

PPS - My biggest problem is I try to be ‘flexible’ but it always ends up causing me grief.  You’ve got to be hard nosed with clients throughout the process if you want to stay sane, and in business.

#19

One thing that sucks: designers who are willing to promise anything to get the job, even if/when they eventually fail to deliver. They ruin it for everyone else because clients, once they hear from a prospective designer who says, “Sure, absolutely, I can do that! I can do anything you want!” they expect that from the other designers they’re interviewing/considering. 

Soooo, if you’re trying to get a job while being honest with the client and setting responsible boundaries up front, some clients just see that as inflexibility. 

It sucks.