I’ve been popping around Feedback finding many of my feature requests have been already asked years ago.
A lot of them are really simple, like user definable indentation levels. I grew up coding with tab-indents and can hardly see these simulated two spaces.
Yet there are staff responses like “what problem does that solve?” or closing them as “by design.”
Or Line Numbers next to the editor. It’s a very simple, very common feature; yet Xojo developers refuse to add it; again by design.
Why is the staff so resistant to regular features? Wouldn’t you want to make it easier to switch?
You guys have been here for years, is there something I missed?
[quote=85026:@Tim Parnell]I’ve been popping around Feedback finding many of my feature requests have been already asked years ago.
A lot of them are really simple, like user definable indentation levels. I grew up coding with tab-indents and can hardly see these simulated two spaces.
Yet there are staff responses like “what problem does that solve?” or closing them as “by design.”
Or Line Numbers next to the editor. It’s a very simple, very common feature; yet Xojo developers refuse to add it; again by design.
Why is the staff so resistant to regular features? Wouldn’t you want to make it easier to switch?
You guys have been here for years, is there something I missed?[/quote]
Lets put it this way - I used to be just a regular user like anyone else here. Really.
Then I got hired 6 years ago thinking “all those simple & annoying things I’m just going to blast through & fix them all”
Yeah . right I’ve fixed a handful.
I’d guess if you asked Greg, since he’s the next newest hire to work on the IDE to any extent, you’ll find much the same.
From outside there are a lot of things that seem “simple to do” until you actually get to trying to do those simple to do things and find out that theres much more to it than you’d ever have guessed & implementing this one “simple thing” turns into a rabbit hole from which you may never emerge.
My personal favorite is #3624
This one seems simple at first and enormously useful - and when you get into it you find you actually have to change the entire VCP format to make it possible and not have really gross side effects - which turns into an enormous task
Line numbers and user defined indents are probably not on this scale - but they do have a “cost” - which is usually something else isn’t getting worked on
In the prioritization of what bugs & user requested features to work on there’s usually an ordering
crashers
project corrupters
bugs
new features
And toss in things we HAVE to do to keep up with OS changes and to keep the product moving forward (iOS, 64 bit, new compiler, etc)
The reality is that things like user defined indents & line numbers just don’t rank highly in the grand scheme of things to do
I work almost exclusively on the IDE and I already have a list that will keep me busy for years (literally).
You suggest when I tackle this & then you should be prepared to defend it to everyone waiting on iOS, the new compiler & all the rest of the things that require IDE changes since I’ll need to delay work on those things. And to anyone else who has submitted some other feature request since if I work on your request I’m not doing theirs at that time.
Its not always “we don’t want to do this” but sometimes “in the grand scheme of things its just not that high of a priority”
JUST FYI - line numbers can be seen in the lower left of the code editor by moving your mouse over the code
I would rather XOJO engineers invest their resources in “MUST HAVE” (ie. broken IDE functions) as opposed to “nice to have”.
A “nice to have” have a minimal impact on productivitiy, while a “Must Have” has a much larger once (hence “must have”).
I wonder if the internal bug system has some way of assigning a difficulty level? The system we use at my work (home brew) allows the developer to assign an estimated difficulty level (easy, medium, hard) and a priority level (would be nice, makes life much easier, must have).
I’d say once every month we go through and spend 1-2 days just picking low hanging fruit. They might not be of the highest priority or even of the highest productivity boost, but wow does it make the users feel good. Further, it makes the programmers feel good. Why? A lot of tickets cleaned off the list, looking at the bug list and seeing a decent reduction in it or for the user seeing a good deal of FRs implemented.
I’m not saying everything we request and think is easy, is actually easy. But, there certainly are easy tasks in there that could be hammered out in a matter of minutes I’m sure.
Can’t edit my post… I was going to say, the bug system is intentionally simple. (3 priority levels, 3 difficulty levels), because that makes it easy to choose and easy for the user to understand. When a system has a priority of 1-10 or a difficulty level of 1-10, that’s just too granular.
[quote=85038:@Dave S]I would rather XOJO engineers invest their resources in “MUST HAVE” (ie. broken IDE functions) as opposed to “nice to have”.
A “nice to have” have a minimal impact on productivitiy, while a “Must Have” has a much larger once (hence “must have”).[/quote]
My personal request is
“I was feeling insecure” sings late John Lennon.
I have to say that when I run the IDE, I am feeling insecure. Every here and then, something happens (no more code in the Code Editor, where is my Mouse cursor, ) to me and I am asking myself What have I done ?".
And I do not talk about Beeps because most of the time the sound is shut down. It happens to me to code at time when people are sleeping, so no sound is allowed.
So, bug squash and Xojo pushed to goût du jour are first to me (with a taste of “better” XPlatform compilation).
goût du jour is translated to last style by systran, but I am not sure that this is what I have in mind. I think more to “Modern” than last style.
Low hanging fruit bugs do get fixed sometimes. If I see a bug come in that’s a quick fix and I’m stuck on my current problem, I’ll sometimes go fix the simple one, just to clear my head.
Go look at the release notes for the last few major releases, and you’ll see that we DO knock out a lot of bugs each cycle.
The main thing is that we all have our own focus areas, so you guys need to remember that what I work on does NOT take time away from the compiler work and Norman’s tasks don’t affect the Web framework (for the most part ).
I am sure I probably already know the answer to this question but if the workload is so high at Xojo Inc then why not take on more coders to tidy up the issues that cause users so much frustration. My guess is that you are going to say it boils down to money but would still be interested to know if that is or isnt the case.
BTW… just want to be clear on the thread. I was just saying something we do here at my work, was not complaining about Xojo or the work they do Sometimes I wish there were 6 rX (not .1, .2) releases a year instead of 4 but, oh well. I know how much work a release is (at least for our software) and I’m sure a Xojo release is much more work than our internal apps.
Greg it is very obvious that you guys work hard to make Xojo great and to help the community as can be seen by you and others being online to help at what seems like any time day or night.
My question was really that people are saying that things on the Feedback list dont get done as they get pushed back and from using Xojo for the short amount I have I do find that their are many things (especially with the IDE) that fight you. I also fully take on board that what may seem like a small change is often very big and could bring instability elsewhere. I guess that part of the frustration comes from not really knowing from the Feedback system if it will ever get done, by that I mean in a reasonable timescale, 2-5 years is not realistic I would suggest.
I know it is difficult to bring on new people and it takes time for them to get up to speed but I would have thought that their is enough “bits and pieces” in the Feedback system and from posts on this forum to keep an additional couple of engineers busy. So why not take on additional staff to crack on and get these things done as once they have completed the list their will always be new things added so it is not as if they will ever get bored!!
[quote=85138:@Nathan Wright]My question was really that people are saying that things on the Feedback list dont get done as they get pushed back and from using Xojo for the short amount I have I do find that their are many things (especially with the IDE) that fight you. I also fully take on board that what may seem like a small change is often very big and could bring instability elsewhere. I guess that part of the frustration comes from not really knowing from the Feedback system if it will ever get done, by that I mean in a reasonable timescale, 2-5 years is not realistic I would suggest.
[/quote]
The biggest problem with Feedback is that most of the reports (bug and feature requests) are just plain awful. They don’t isolate the problem. They don’t provide a test for whether something is fixed. Unfortunately, that takes a lot of work which many users are either not experienced enough to do or don’t have time. Double unfortunately, this work probably needs to be done by the users reporting the problem because they have the actual contexts that expose problems.
If I were building a Feedback system for a product like Xojo, what we call Feedback would be Report Purgatory. Bug reports and feedback requests would graduate to Numbered Reports when they meet some high threshold of actionability. There would be positive (but non-monetary) incentives for bug reporters to contribute and refine projects that demonstrate bugs in Report Purgatory to bring them closer to actionable. Report Purgatory could grow as out of control as it will. Ultimately, we’d count Numbered Reports to reflect how well we’re responding to things,
Is there a way to see exactly how many tickets are in the bug/feature request queue? I can imagine its quite large. An actual number might put it into perspective for everyone as to the queue/employee-developer ratio. Theres a lot of thought and planning that has to go into coding even simple fixes since even a minor change could impact something else in the code hierarchy (thus breaking something else or causing undesired results somewhere else). Kudos to the bugs which do get fixed. And for those that arent, there are usually work-arounds or other solutions available in the meantime such as custom TextAreas which already allow more than anyone could ask for (including custom indentation). Kudos to the developers… as a developer, a task is always easier to contemplate than physically implement. We forget that in perception we can only see whats “in our view scope” and usually forget that outside our scope is “an entire world”…things “unseen.” Thinking about going to the store, and actually going to the store, could be easy or very difficult depending on obstacles which may manifest in your path of travel. The developers at Xojo at least take the time to take the journey step-by-step accounting for each obstacle along the way… so while at the intersection of StyledText and Margin-settings you dont get “T-boned” (so-to-speak) in your code. Patience is key…and for everything else there’s usually a way around a “show-stopper,” and if not those are the bugs which get focused on first. Bad comes to worse since textareas are native controls, you can always hook into them and use system apis to “make the desired changes”…just like in windows im sure the underlying c/c++ code to create a textarea uses createwindowex api and either “TEXT” or richtextedit4 (hopefully not 2 :-/) window classes to create a textarea (assuming it as a native windows control). Using windows api on such a case you could always apply extended properties to the object by handle (ie margins etc). Where theres a will, there is always a way. Im sure Xojo’s plates and cups more than “over-runneth” with plenty to do to TRY to keep everyone happy. For all that’s wrong, don’t forget what’s right. No one likes to do hard work and feel unappreciated. …which most people always forget, until its them.
This only came because I’ve seen a dozen “your product sucks” “im not getting a new license because…” posts this week and I think we all forget what I mentioned. I believe money would be an issue as the development crew is slightly limited in number, there are a little over 800,000 xojo developers (not saying they renew licenses or have in years)…theres the cost of the xojo, inc. main office, electricity, supplies and utilities, employee pay, customer interaction expenses, cloud sub-licensing through rack-space, and im sure 100 other annual expenses Xojo, inc pays plus taxes aside. Thats really not a lot of money. I took this under perspective 2 years ago when I started self evangelising about RS/Xojo to schools, local businesses etc and attempting to get a customer “explosion” but for some reason people are reluctant. Ive been dabbling in the LiveCode community to find out how they managed to have under 300,000 users for almost 10 years (under runrev) and suddenly after the LiveCode community release (last year) have over 2 million commercial licenses and almost double that of “community developers”. Surely they are doing something that appeals to a wider audience? (I doubt the open source edition has anything to do with it as they had that for a while and suddenly opened a kickstarter to expand it).
If only the problem of “how to get a Xojo revolution” started could be solved. … how to get people excited about coding… excited about Xojo!
Then after that, it would come down to the final bit of code…
if greed then
Outcome = "deeper pockets, same product, more users, grumpy underappreciated developers and community"
Else
Outcome = "minimally deeper pockets, better product, more users, happy overlyappreciated developers and community"
End if
Return Outcome
A little (lot?) off the topic, but you peaked my curiosity there, Brad … you must have been raised Catholic, cause since my altar boy days (so long ago that my ‘non-altar boy life’ has almost totally obscured it) I haven’t heard that word “Purgatory” used by many that weren’t raised Catholic. Usually you’ll hear “limbo” (e.g., “it left me in limbo”)
i’ve been following RunRev or LiveCode since it was available. What I noticed is that they rapidly expanded the amount of add-ons, plug-ins or whatever you want to name it. That attracts users, I’m sure. If professional users take a look at a new product they have something in mind it should be capable of. Can I connect with my UltraSpeedUnixDatabase? How easy is it to implement a HTTP class? Does it run on iOS? In that case, LiveCode fills a gap. If Xojo releases its iOS framework I’m sure they gain much more attention. The trick is to turn window shoppers into license buyers.
A super-stable, super-dependable IDE would go a long way towards that goal. I am still fighting (and that is the correct word) focus and copy/paste short-cut issues on Windows. Searching for project items can be taxing in big projects. I’ve learned to just hit CTRL-C, three or four times to make sure a Copy takes, but how many users checking out Xojo for the first time are not going look at that as a major red flag? The focus issues can drive you nuts at times, you are typing in one window or field and the next thing you know the cursor is somewhere else as you continue to type. Little stuff like this would make an DEV manager leery of switching tools.
I know the IDE has come a long ways, and it is really starting to shape up nicely. But for Xojo to take the next step, the IDE has to be rock-solid, something you don’t really thinking about on a daily basis. I really hope we get there by the end of by 2014r4.
[quote=85151:@Don Lyttle]A little (lot?) off the topic, but you peaked my curiosity there, Brad … you must have been raised Catholic, cause since my altar boy days (so long ago that my ‘non-altar boy life’ has almost totally obscured it) I haven’t heard that word “Purgatory” used by many that weren’t raised Catholic. Usually you’ll hear “limbo” (e.g., “it left me in limbo”)
[/quote]
I was raised by heathens who worshipped the amateur couple soccer deities on Sundays. But I’ve always had a disproportionate number of Catholic and Jewish friends, and while I’m not about to sign up for any religious affiliation (I’m a card carrying “apatheist”), I have found many Catholic and Jewish traditions and themes quite practical to apply to life, even in these fast tech-driven times. It’s really no different than “geeks” who allude to Star Wars and Battlestar Galactica (2000s, not the campy 1970s version) all the time.
[EDIT:] And I find a great deal of comedic value in Dante’s Inferno. Probably what really sparked the usage there…
I wholly appreciate how massive Xojo is as a project, and it works well for everything it does. But growing up as a Mac user I expect things to just work, and be easy. I honestly cannot fathom why there’s no indentation control, it really puts off users who have difficulty seeing.
Anywhoo, the topic is about why we get such negative responses to feature requests on Feedback, and why most of them never happen. I agree more clarity as to what kind of workload is going on would answer a lot of questions. User accessibility should be among one of the top priorities however. I would think retaining users with difficulty seeing is far more important than this already implemented doohickey:
As for a Xojo revolution, or converting window shoppers; my suggestion (on top of the clear winner of iOS) would be to take a hint from Apple and make it easier to switch. That includes being able to read your code, not punishing users for semicolons, and line numbers at a glance. (read: having to move your mouse over a word is not at a glance)
I’ve fixed a handful.
).