Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
on larger projects i use a simple bug tracking system that's designed to be used by clients
i have a lot of trouble convincing clients to use it (they send bug reports via email)
does anyone have any strategies they can suggested?
also, i have been playing around with a theory as to why this is the case; it goes like this:
asking a client to log a bug is like taking your car to a mechanic for a service, and the mechanic hands you the engine oil and says "here, pop that in". basically, the client has paid you to do the work, logging a bug sounds too much like work, so they want you to do it
thoughts?
A clear, concise bug report, not attached to a refund request, is about the best thing that can happen to your development effort, no matter what format it arrives in. Free QA, dude! Why would you want to hinder that process by making the customer jump through hoops to learn your bug tracking interface? Even if they're also in the software industry, maybe they come from a Bugzilla shop instead of a Fogbugz shop...
First, make sure your tracking system is very user friendly.
It has to be easy to access. Does your client have to go to a web page to file a bug? Is the application buried deep in the sitemap? Nobody is going to open a browser, find your site and go through numerous links just to file a bug. This can be solved by putting a link in your application (again, it has to be easy to find; like Help > Report a bug). If your client has more then one application, make sure he is directed to correct page (or pre-fill the needed fields).
Next, do not require of your client to classify the bug (like severity and whether it is in fact a bug or a feature request). Also keep number of fields low. Description and a screenshot is plenty.
Make your controls easy to use. Nothing is more frustrating like having to wrestle a datetime picker with three drop-downs when you are trying to get some work done (and of course if you select day 31 and then April, day gets reset to blank value).
If you expect a screenshot, give your client a nice silverlight control, where he can just drop the file instead of searching it all over his disk.
When your bug filler is customized so your own mother can use it, you'll still have to push a bit. Try to "forget" about the email sometime and when the call comes act surprised and ensure your client that you received no bug report from him. Of course when he insists that he did send it to your email, have an "ah" moment and inform him your email is acting "strange" lately, then ask him to resend the email. Next bug report will be filled right.
Fogbugz... I asked my clients to open a case about their bug and i then worked on it... Its really worth a try..
I second the recommendation of FogBugz. Most bug tracking software is a nuisance (I'm looking at you Bugzilla). It's just too perceived as too difficult to learn / navigate by my clients.
FB lets you have a public submission page for submitting new bugs. This is a very simple page that your clients could learn easily.
FB also lets you receive e-mails directly into the bug tracking system. As the admin, you categorize / assign incoming e-mail. Then, your client could optionally be notified when the bug is fixed.
One last plug for FB: There is a bug submission tool which lets you send a screen shot from a machine along with a bug description. This has been handy for my clients as well.
The final advise is this: Stop fixing any bugs that are not in the bug tracker. Of course you will get push-back, but not as much as you might think. If you are responsive to bugs / feature requests that are entered in to the tracking system, your clients will begin to see value. But, like little kids, they will not change if they can still get what they want by just fussing a little.
IMHO I think it depends on what type of client it is, if you work as a freelancer for small companies then I think a excel spreadsheet filled by yourself is enough to use as a bug tracking system.
You probably need to point out the advantages of the bug tracking system for the customer like easier for them to see the status of the bug, prompts for mandatory information like version number etc.
Above all the argument that if they use the system their bugs will be processed faster usually does the trick.
Set up your email server to bounce emails with the word 'bug' in it. Have the bounce report contain a link to your logging site.
(Or in reality, get a bug tracking software that allows bugs to be 'emailed' in).
You assert that your bug-tracking system is designed to be used by clients, yet clients won't use it. Could be something wrong with the clients, could be something wrong with the bug-tracking system.
I've always liked rt because it does have about the simplest, email-based user interface for clients.
However, I'm not suggesting that you change your bug-tracking system. What I would suggest is that you discuss the situation with some of your more friendly clients and see if you can figure out why they don't use it -- sure you've got a theory (some thoughts in your head) but do you have any data (some of the thoughts in their heads) ?
Then change to rt :-)
That last bit was a joke, what I should have written was -- then when you know what the problem really is, you can think about fixing it. Changing from system X to system Y without discussing the situation with your clients would be folly.
Even more foolish would be to start getting all snotty with your clients and bouncing back their bugs because they haven't filled out the right forms (as some have suggested). Unless that is, you are working in a secret orchard where paying clients are waiting to be plucked ripe from the tree.
If they're sending their bug reports to you by email instead of using the bug tracking system, give them the email address of the bug tracking system! Of course you would have to implement the feature but it would be novel to parse the email for inclusion.
If the email is in the wrong format the bug tracker will email them back with a template that contains the correct layout for them to fill in along with the original text they sent to cut and paste accordingly.
If they still send the email to you, forward it to the bug tracking system and when you get the reply with a template, forward that info back to the client and tell them the system won't accept it. This is still a bit of a manual process but you will be training the client at the same time on the medium they prefer and they're still doing the majority of the work.
Automated Return email might look like:
From: Bug Tracker
Date: 25/3/2010
Subject:
Please
reformat your bug report: [original
subject line]
Name: {Your Name here}
Priority: {Number here from 1 to 3}
Report below
this line (when done, email to bugtacker#example.com. Thanks!
{ your original text }
Go for a House M.D. style approach:tell them straight on that you're not reading any emails concerning bug reports, they go straight to Spam folder. You've got, however, this nifty interface for logging bugs, and by using that they're making sure that you'll get to see them.
Related
My client needs data scraped from a website. I am planning to use php_curl. The problem is, the site is using Google reCAPTCHA. Few powerful data items are visible only when you click "show this information link". then the reCAPTCHA appears in lightbox and vanishes, and information is displayed.
I have checked the source html, the protected item is actually loaded when someone clicks, and there is no way for me to automate this click. I have even tried to open the site in iframe and then use JS to click it, but it fails as both domains are different. I have also tried to use Selenium stand alone version but its downloads are corrupt.
Unless there is a design flaw with the website, the reCAPTCHA will prevent you from scraping the material without human intervention.
Technically, your best bet is to employ humans to solve CAPTCHAs all day and write some software to automatically scrape the material it protects for each one they solve. A number of viable businesses have been created this way, where the data is valuable and there is a genuine public interest in opening the data-set. (For example I heard that flight companies use CAPTCHA devices to prevent price comparison sites from driving down the cost to the consumer, and I'd argue in such a case there is an overwhelming public interest to defeating such defences).
Morally, however, you would need to tell us what you are doing in order for us to advise you. It is possible your client is merely planning to steal other people's material and then attempt to monetise it for him/herself, even though they had no hand in creating it. That may breach some copyright laws, but moreover, they (and you) need to decide if the scraping is fair.
I am facing the same problem but resolved it using clear my cookies in httprequest in useragent after clear cookie wait time function (tread sleep) for some time and then start scrapping again. But I am doing this in C#, not in PHP. Applying this logic may help you.
In my app, I've got a share button for facebook and twitter etc. I want that people can tweet and post the link of my app, but the app is not yet available in the app store, so i can't have a link to the app.
In some apps there is a link to the app if you are composing a tweet, how do they do that?
As H2CO3 pointed out, having that AppStore URL delivered from a server you control would likely be something you would prefer. Naturally, the first question to pop to mind would be something of the form 'Why do I have to use a server at all? Can't I just code it into my app directly?'
In short form, you are not required to use a server, but you may find that the benefits and flexibility it offers you in at the cost of a little more networking code and complexity in your app helpful. Let's expand on this a bit, by imagining we lived in the perfect world where we knew with 100% accuracy what that AppStore URL would be and that it would never ever change. We could get away with just coding that URL directly into our app and we would never again have to think about that part of our app -- it would always tweet the correct URL, users would be happy, and you as the developer can turn your attention to more important matters.
Unfortunately, things often don't work perfectly and as software developers we have to consider the ugly edges of reality and write code to handle them gracefully. Here are just a few of the potential problems with hard-coding a URL:
We don't actually know the full AppStore URL.
Apple may decide to change AppStore URL formats and render old URLs invalid.
Despite our best efforts to carefully type the URL into our code, we made a mistake and now we have to issue an update and wait for our app to be reviewed to get a simple typo fixed - Eep!
H2CO3's suggestion to use a server builds likely stems from experience in writing software coupled with developer's inherent risk management driven thought processes -- if there is something I can do to make my software handle these ugly edges more gracefully and make my software more reliable, it may make sense to take the extra time to implement my feature differently to protect it from the shadowy unknowns the future may have in store for my app.
For the sake of a balanced argument against putting the URL on a server:
If your users are in a place that has spotty cell or wifi coverage, they may not be able to connect with your server to get the AppStore URL from your server
Your server might not be working properly so it can't deliver information to your app when requested.
Adding a network request like this can be very easy to do, but also introduces its own set of risks to have to consider (isn't writing software great?)
As indicated above, you do not need to make your app snag the URL from a server you control, but you may want it to do so. Only you, as the app's developer, can determine what degree of risk you are willing to accept and which of the available options you've researched, invented, or otherwise acquired seem to fit your specific needs the best.
Since I don't know your background, I'm going to stay relatively high level and give you another couple of nudges in some directions you can go and do some additional research:
On the 'setup a server' idea -- you can purchase a hosting account from a number of hosting providers around the Internet or if this is a school or work project you may be able to speak with your IT people to request space for a website. After you have that setup, you can put a file on that space with a placeholder URL and write some code in your app to connect to your server and read your file (that has your fake URL in it!) the put it into your Tweet. Once your app is approved, you can change the fake URL on your server with the real one, and your App will work like you want. For the App part of things, you might look into some of the simple +stringWithContentsOfURL: methods on NSString (though do remember to consider things like what happens if the Internet is down, or if you don't get anything back from your server, etc.!)
On the 'just hard code the URL into the app' idea -- Apple makes some marketing resources available to developers even before they release an app. Checkout (https://developer.apple.com/appstore/resources/marketing/index.html) with an emphasis on the Shortlinks section, and also checkout Technical Q&A 1633 (https://developer.apple.com/library/ios/#qa/qa1633/_index.html). Both of these links give you information about how to build a link directly to an application or vendor on the AppStore given just their name(s). Like before, do remember to consider what happens if you ever decide to rename your app, or if linking elsewhere (or maybe nowhere!) would make more sense.
Hopefully this will help you think a little more about what you are actually trying to achieve, and give you a sense about what other developers think about when faced with decisions like the one you've posed here.
While i agree with Bryan i always avoided using servers for basic things. With ios 5+ you can send tweets from inside the app ( and you can add default tweet (i.e. a link to the app)
Your problem can be solved easily this way : make a short link with the link to the app store ( the link to the app store is formatted like this : https://itunes.apple.com/app/id <app id> , and the app id the the one in itunnesconnect under Apple ID )
For example you can make a default tweet like this : " Check out this awesome app!! goo.gl/buya " and then the user can edit it as he wishes.
Also..it's extremely unlikely that Apple will change the format of theyr links...too many users depend on this format to do..a lot of things
Now, I see many apps that will say "started using [Name of App] "Is that simply a call to StreamPublish or is there a new function call to achieve this?
I am currently using facebook to allow people to log in with their facebook accounts similar to turntable.fm and then going to my webpage. How do I make it so that other friends can see that they started to use the application, I have not been able to find this anywhere.
There is a setting on your application for "social discovery". Enable it and those posts will show up.
sorry, this is not an answer but clarification of the questions and answers (I don't seem to have enough points to be able to comment)
Firstly I'd like to say that if you are developing a Facebook app this would seem to be a very important question as it would have a huge impact on the virality of your app. It would mean that every single registered user is potentially advertising your app to each of their friends. Without out this happening your only options for viral spread through facebook are:
asking for 'publish_stream' permission and using the 'Post to wall' API call. Asking for this may deter many users from using your app in the first place.
User initiated sharing (like button, post to wall). Unless your app was amazingly awesome you'd be lucky to get a 5% rate with this (as opposed to the 100% rate you'd get with the mysterious 'started using' feed post)
I created a fake account for testing, created a facebook app (as a webpage, not as a facebook app/iframe), made sure social discovery was enabled, but I could not see any activity on my ticker or my feed. However, I did learn that there is a thing called the 'canvas ticker' which is completely separate from the 'main' ticker and can be seen when you use any facebook iframed-app. A notice did appear in the 'canvas ticker' but it said 'a is using b' not 'a started using b'. Getting a message on the 'canvas ticker' is not nearly as significant as getting a 'main ticker' or news feed post as relatively few people use 'facebook iframe apps'. I thought that this is what I must have remembered seeing (not seeing 'started using' in my news feed or main ticker), so I gave up worrying about it.
However, recently I started using Graph API Explorer http://developers.facebook.com/tools/explorer/ and a 'started using' post appeared in my alter-ego's news feed. That is exactly what I remember seeing with other apps ('started using' rather than 'is using') but it seems to be quite a rare occurance. I'm not sure if anything appeared in my alter-ego's main ticker.
Now I am really confused. This feels alot like figuring out how google's pagerank algorithm works.
update:
this link has proved quite useful: http://developers.facebook.com/blog/post/410
I think 'started playing' only applies if you app is set to having the 'games' category. Apparently these 'started playing' stories only show on the newsfeeds of people who have already started playing the game. So they can't really be of much use to gaining new users (as only user who are already using the app see it). However, the blog post states,
"By showing fewer but more impactful News Feed stories based on
friends’ activity and social context, we hope to drive new user growth
for games. For example, instead of the typical story saying that
someone just bought a new item, it could say “Dave, Jonny and 3 other
friends” just started playing a game."
I am really confused by this. How can the 'started playing' story possibly 'drive new user growth' if they only appear to people who are already playing??
The 'x started using Graph API Explorer' seems to be a really odd one. I think because it's an app made by Facebook it has special priority and that's why it showed as a story in all of my friends's newsfeed. I've been installing a lot of non-game apps to see if the 'started using' story appears but I could not find one that did. I'm now not sure if I ever remember seeing a 'started using' story. I installed games such as Farmville and Sims Social and yes i did see a 'started playing' story on my alter ego's newsfeed.
Why is that incredibly hard to find blog post above not part of the official documentation? And why doesn't the blog post explain exactly how things work with good and thorough examples instead of being really vague. I think every app should have an equal chance for viral growth without having to spend hours conducting psuedo scientific experiments with fake user accounts just to figure out how things works because the documentation is poor. I'm sure players like Zynga have the resources to figure out facebook inside and out but this is getting really frustrating as a sole developer.
This is why I'm hoping for a day when the prominent social network's code is open source. Nothing beats being able to directly read the source code when documenation is poor. That is one of the great things about open source.
Hey this is a common question I hear from my clients whom I write FB apps for.
It's called the FB User Discovery Story and it's automatic. Facebook eventually enables it for applications. There's nothing you can do to make sure it's displayed and it's visibility is effected by the evoking users privacy settings as well as the receiving users settings.
Also, note that it does not require your application being in the app directory.
The new facebook application interface allows you toggle the feature on and off but it still relies on the users settings as well.
We should be able to access some of it so that we can edit the placement of each GUI object inside of CoreGui. So, other than security reasons, why are we not allowed to edit placement of GUI objects?
Also, why can't trusted users use CoreScripts? What if they need to access HttpGet so they can provide a nice display showing where their best friend is at the current time and place? SocialService won't always do the trick.
Can a developer (or any other experienced Roblox player, particularly one that knows the UI in and out) please answer these questions to the best of his/her ability?
I asked this in the OBC cast, specifically about editing the UI inside CoreGui. I'm not sure what security reasons could be preventing this, however. They did reply - the answer was, "Well, we definitely don't want you moving the little help icon, or the exit button."
I got the feeling the general reason is because users would become confused if everything was misplaced. For example, if you went into a website where you could play several games all made by that company (like ROBLOX), would you expect the exit or help buttons to me placed differently in every game?
They did say we will be able to change the colours.
Hope this clears things up.
Some GUI objects like the report abuse button we don't want users to have the ability to be able to remove. Another sensitive area is the chat window. If it was completely scriptable, you could write a script to make it look like another user was saying something that he wasn't. This is not really desirable.
HttpGet is currently a privileged function for two main reasons:
It would allow users to get dynamic content into levels, which would make moderation a more difficult task.
Poorly or maliciously written scripts could HttpGet roblox.com in an infinite loop, sapping our server resources.
There was no obvious benefit, but some obvious downsides. We prefer to solve only the problems that need to be solved in order to ship features, so we err on the side of caution for things like this. If we later decide to open up new functionality, like making the ROBLOX social graph available through an API, we can do that with a dedicated interface that limits the number of requests you can make to the website in a given period, and only return the info that we are sure we want you to be able to get.
It's interesting to note that for a very long time Adobe Flash player didn't support TCP sockets for the same reason.
I have built a little Web UI for Pidgin(respectively all libpurple based messengers) together with DBus and Sinatra.
It was for fun and learning purposes and now I'm looking for ideas to extend it.
Can you think of any useful applications or extensions for it?
Since I work on this project to learn something new, ideas for other technologies to be used/combined are welcome.
Finally here is the link: pidgin-web-ui
I few things that that might use to many many people would be:
good and simple to configure https support, so that users in "monitored" countries to be able to still chat freely (if the server is somewhere else).
Unified Message Archive . Many IM clients have various archive functions, but are different, limited, hard to search, and many are "client only", so not accessible when one needs them the most. Since Pidgin can connect to so many IM networks, it would be cool to have such a "global message hub archive". This would ensure that everything the user is talking is archived (very useful for businesses too), easy to search, available on a server (so always at hand).
File Archive on the server. The same as the Unified Message Archive, but for the files/images users exchange. Having them on the server (with a hash for easy sync) as a backup and archive would greatly reduce the traffic if they need to be shared more than once.
The would be many more nice features, that would help many users, but the above 3 seem to miss from usual IM software.
My idea after a brainstorming minute:
Dropbot
Create a messaging account anywhere and add this account as a contact to your messenger. This contact is your Dropbot.
Change your interpreter UI so it does not display a conversation but a log. In this way you can just drop things to the contact like interesting links. There could be a Dropbot for a read later queue, your favorite citations or for a list of funny findings.
You could then extend your UI to a little mashup. It could follow the links and grap the title of the page and a content preview just as Facebook does it when posting a link to your wall.
You could further extend your app by adding post-drop behavior to the Dropbot.
Dropbot could post your link (probably with a message) on Twitter or Facebook.
Dropbot could automatically distribute the link to the other contacts of it (like your friends)
Ok, that sounds fine... but you could do that without a message bot inbetween. What's the deal?
For me the advantage would be that my IM is always open and it would be fairly easy to drop a link. You could do the link dropping with Delicious or post stuff to a Google Wave, yeah. But I don't like to go to a web page, log in and organize stuff in the UI. Actually I stumble upon those links when I should do more important stuff instead. So just dropping it to my IM Dropbot contact would be cool.
Why not extend it to cover all the basic features of instant messaging (sending/receiving messages, adding contacts, etc...)? Seeing how many features you can reproduce may be a fun exercise. Create your own little Meebo...
Want to have fun?
Make a Markov-chained-based chatbot integrated into the web app. Make it use scraped web search results for the content, after searching for terms parsed out of the human's responses. That should be fun, and will give you funny, and sometimes eerily smart-looking results. Have fun!
I have seen your code. Why not split dbus_thread into a event_machine daemon for further scalability?
Integrate it with Twitter. Trace conversations (#Replies), including multi-party involvement. Log them. And so on.
Many interesting features and a popular, original API to learn.