Dec 24 2015, 12:17 pm
|
|
Wirewraith
 |
It didn't occur to me that there might be some misunderstanding there. Yes you're quite right, in the web world "responsive" means exactly that.
|
Yes, sorry this is a very common term, so didn't think to explain it. Ton's of derailing on this thread too...
Anyways, just go to the URL below and keep decreasing your browser's width to see an example of responsive design. http://getbootstrap.com/examples/jumbotron/ Google's search results now favor websites that are responsive and modern websites are designed mobile first. If BYOND wants to tap into the mobile market with the web client, this needs to be done and I don't think it would be that big of a deal using something like bootstrap (if you don't want to write out the CSS yourself). | |
Problem is BYOND uses a shit ton of tables. Tables aren't that responsive friendly ... Unless you want to add another jQuery library to compensate for that or rewrite how those tables get output..
So there would be a fair amount of work involved, it would benefit BYOND IMO and would hopefully finally get it out of its 1990 web design phase.. This website and it's colours are so ugly. | |
One reason the colors are problematic is that every time we tried to switch to something cleaner and more modern, people went nuts and started demanding changes.
A lot of the table stuff can probably be dropped now; much of it is a holdover from darker times when it was the only way to get stuff done. | |
Yeah, I work on a cloud-based inventory management system and I know what you mean. We can move a single input and clients call in freaking out -- sometimes we end up doing conditional layouts to make them happy with a setting to toggle between the two.
My philosophy is that you can't make everyone happy though. In the case of BYOND people will just get over it and move on after a couple weeks and a number of threads. Not related to original topic, but a new look could definitely improve BYOND from a marketing standpoint -- the first thing people see when considering BYOND to make or play games is the website. Many people will decide in under 10 seconds whether they will hang around or not. I actually wrote my first line of code in DM when I was like 18 years old and couldn't figure out what this magical "variable" people keep speaking of for hours -- now I am a full-time web developer. So, I just want to see BYOND reach its potential because it helped me decide my career path which has been a huge blessing to me and my family. | |
@LummoxJR: Can you respond to my post? http://www.byond.com/forum/?post=1999943#comment17779767
| |
NullQuery wrote:
Lummox JR wrote: You don't "know" that. The site developed in a somewhat organic way and accrued a lot of changes over time. Lots of things that seem like they would be trivial are not, because of slightly different design elements across different pages--things that at one time fit the site perfectly, but as things changed they didn't fit as well. If I was starting from the ground up I'd definitely do a lot of things different, but a lot of the site's pages are the way they are because of their history. And it's easy to say that such and such may be a simple CSS tweak, but even when that's ostensibly true it often turns out, in practice, not to be true. During our last big site update, you may remember the fact that people had issues with the login box and requested a few changes. Those changes turned out to be excruciating, because they required whole new markup and needed things to be moved around and styled in ways that were not as easy to do in CSS as they seemed, on the surface, to be. Heck, even when a site is built completely from scratch with the very best practices, things that look trivial from a design perspective often turn out to be brutal in implementation. Recently I reported a bug with savefiles where the savefile wasn't closed correctly. Not only is savefile.Flush() still not part of the language which to me sounds trivial because you could get away with copy/pasting the code for savefile.ExportText() and removing the parts that deal with creating the text file, but the documentation also hasn't been updated to reflect the behavior of fdel() which if used on an open savefile sets savefile objects to null which may confuse developers. I said: "savefile.Flush() looks doable. I'll put it on a list for 510." And so it is; it will be implemented in 510. It is a trivial feature, but it couldn't be added to the 509 series because 509 was already out. Any time new procs or vars get added, it absolutely has to go with a major version bump. The code does not differentiate between minor builds, only major ones. This is pretty much true of network message changes as well, though I made a rare exception in one of the early 509 builds. The kinds of features that can be done in minor builds are ones that don't impact the network code and don't alter the language. Obviously I can't say with certainty that savefile.Flush() would be trivial since I'm on the outside looking in, but I know that updating the DM Reference is trivial because there's no actual programming involved, just modifying the text. To be honest I don't understand the point of modifying fdel()'s documentation. I don't see why it wouldn't be clear that, if you have a savefile open for a specific file, deleting the file would null out the savefile reference. That's the exact behavior I would expect. But I'll grant that I'm behind on working with the reference improvement thread overall. There are some things there that I could implement. My greatest fear working with the BYOND language is that one day you'll quit working on it and the language will be open-sourced. At that point, I feel any project I have is going to be moot because the community is set up in such a way that a lot of copycats are going to pop up & I won't have any official way of publishing my work without having to deal with the engine. An engine which I frequently hear complaining about due to its age and lack of modern language support (i.e., lack of C++11 support, compiler is difficult to modify). Sometimes even trivial changes aren't implemented right away. But in the case of savefile.Flush(), while it is trivial it couldn't be done in 509; hence why I said 510. I wasn't clear on that thread that the new proc issue was the reason why I said 510 instead of 509, but that's the reason. These larger features are going to take up a lot of time, and IMO it's best to improve the software overall even if it means that the larger feature is going to be delayed by a week. The webclient login interface is very much on my to-do list, and something I intend to get to quite soon. I'll see if I can take some time away from the software to get that done, although it's hard because I'm obviously pushing hard to get the first 510 out--which will include the savefile.Flush() feature. | |
Lummox JR wrote:
NullQuery wrote: Look, I'm not stupid. I know that some things may appear to be trivial when in reality they aren't. And I don't have BYOND's source-code in front of me nor as many years experience with C/C++ as you. But claiming that changes are never trivial is bogus, and those kinds of statements are what I'm worried about. More on that in a bit. I said: "savefile.Flush() looks doable. I'll put it on a list for 510." And so it is; it will be implemented in 510. It is a trivial feature, but it couldn't be added to the 509 series because 509 was already out. Any time new procs or vars get added, it absolutely has to go with a major version bump. The code does not differentiate between minor builds, only major ones. This is pretty much true of network message changes as well, though I made a rare exception in one of the early 509 builds. To be honest I brought up savefile.Flush() because I saw no activity on it for a while. Had I bothered to read your last post one more time I would have seen it's on the list for 510. So I apologize for bringing that up, as you did let me know that it was going to be in 510. To be honest I don't understand the point of modifying fdel()'s documentation. I don't see why it wouldn't be clear that, if you have a savefile open for a specific file, deleting the file would null out the savefile reference. That's the exact behavior I would expect. This is a major problem: you don't see why something wouldn't be clear, so you don't take any action to warn people about it. The fact is that to this day people still put usr in procs, so please consider that not everyone is on the same level with the language and its behavior. From my POV it doesn't seem logical that fdel would even work on an open savefile. You can't delete the file with Windows Explorer, so why would it work if you deleted it from within BYOND? Because the file is locked by BYOND, and your project = BYOND itself? And why would deleting the reference be better? Isn't it much easier to diagnose a fdel() failing because the file is locked for editing than it is to diagnose a variable randomly turning null? IMO this was not designed properly, and I understand that it's not feasible to suddenly change that operation but it could at least be documented so people will know which behavior to expect. Another major problem: you made that decision without informing anyone that you made it. This is primarily what promotes my doubts and issues with BYOND. The primary reason I picked savefile.Flush() as my example is precisely because modifying the reference should only take a few minutes to do. Obviously you don't have to tell everyone about everything since this is your place and it plays by your rules. But come on, you expect me to make use of your game engine and then you refuse to keep me up-to-speed on its quirks and behavior? Don't you want new developers? Because things like this is why new developers will be reluctant to use BYOND to build a game. But I'll grant that I'm behind on working with the reference improvement thread overall. There are some things there that I could implement. If you'll still let me make suggestions ;(, then I would suggest making the reference a bit more dynamic so it can be updated by other developers. Just like how there are some trusted people who can modify statuses on the trackers there could be a small group of people with access to modify the DM reference. Not sure how this would work with the offline reference, but maybe you could have it synchronize the reference with the hub periodically. Ideally someone other than yourself would spearhead this development, so you can focus on the software which none of us can modify. The webclient login interface is very much on my to-do list, and something I intend to get to quite soon. I'll see if I can take some time away from the software to get that done, although it's hard because I'm obviously pushing hard to get the first 510 out--which will include the savefile.Flush() feature. I don't even need the savefile.Flush() feature since I have a perfectly viable workaround. It'd just be nice to know that, ok, this is going to be fixed in 510. Time to close that issue and move on to the next one. Recently you caught me bumping some feature requests up. I did this because there are currently ~1200 issues with the status 'Open'. Where I work this is what we call a failed project -- what I've learned is that you need to keep the open issues down to a minimum or you'll lose perspective and miss bugs. IMO in an open environment such as this it should be doubly so, since people could be reporting the same stuff over and over and if they remain open it'll render the entire tracker useless. In this context, what I mentioned before about statements such as "no change is trivial" worries me because it sends a message that you're giving up on this project, or at least not feeling comfortable working with your community. What I'd like to do (if I'm not wasting my time) is look into the currently outstanding issues and make a list of things that could be closed or that _may_ be trivial to implement. Then we may be able to clear the list up a little. | |
And of course thank you for taking the time to respond (albeit in my eyes over-the-top defensively).
| |
If we're going to mention other random feature requests here, I'd rather mention the fact that you cannot use SSL with the webclient, libcurl isn't implement and Export doesn't support POST.
Along with the fact you can't set a host key in Linux (clients ask me this at least 6 times ever few months...) And a million other things.. Really I don't understand why this was brought up here? Just to grab Lummox's attention (again)? I'm sure he keeps a mile long list of doable or quick feature requests to implement. | |
If he does, I hope he'll share it with the rest of us so we too can know where we're going...
I could implement libcurl as a DM library if that's cool. But I'm hesitant to invest my time in it if Lummox JR is just going to implement it himself in the near future. | |
NullQuery wrote:
Look, I'm not stupid. I know that some things may appear to be trivial when in reality they aren't. And I don't have BYOND's source-code in front of me nor as many years experience with C/C++ as you. But claiming that changes are never trivial is bogus, and those kinds of statements are what I'm worried about. More on that in a bit. Of course there's also room for a little poetic license. In the original post where I said that, it was a short statement. Exaggerated for brevity, though not terribly far off the mark. The point I was trying to make is that site changes that seem simple ahead of time, even to me, often end up being nasty affairs when it comes time to implement and test. To be honest I don't understand the point of modifying fdel()'s documentation. I don't see why it wouldn't be clear that, if you have a savefile open for a specific file, deleting the file would null out the savefile reference. That's the exact behavior I would expect. But calling del on an object will delete all references to it; it seems pretty logical that fdel() on an open file would delete open savefile references to it. Anyway this is something that AFAIK, you're the only one who ran across. From my POV it doesn't seem logical that fdel would even work on an open savefile. You can't delete the file with Windows Explorer, so why would it work if you deleted it from within BYOND? Because the file is locked by BYOND, and your project = BYOND itself? It's true that the file being opened locks it; but since the server process owns the locks, the server can delete it. But I still don't see how the behavior is an unreasonable expectation. I guess it can't hurt anything to document it, but that's been extreme low priority. As a rule no project is going to call fdel() on an open savefile, but rather will try to do all its saving in a single proc without sleeping. Another major problem: you made that decision without informing anyone that you made it. That decision wasn't mine; that behavior has been in the code since before I started working on it. I didn't even know about it until I looked into it, but if I'd been pressed to guess how fdel() and savefiles would interact, I'd have guessed either 1) the savefile reference would be nulled out, or 2) the fdel() call wouldn't be permitted. But in either case I'd have said that if they're interacting at all, it's a bad thing. But I'll grant that I'm behind on working with the reference improvement thread overall. There are some things there that I could implement. No hard feelings at all and I'm still completely open to your suggestions. :) I would kinda like to bring back the online reference, although a lot of its infrastructure was gutted with the last big forum change. I'd be open to some kind of wiki thing I guess. My main concern with such a thing would be ease of setup and maintenance, to avoid putting more time into it than necessary. Recently you caught me bumping some feature requests up. I did this because there are currently ~1200 issues with the status 'Open'. Where I work this is what we call a failed project -- what I've learned is that you need to keep the open issues down to a minimum or you'll lose perspective and miss bugs. IMO in an open environment such as this it should be doubly so, since people could be reporting the same stuff over and over and if they remain open it'll render the entire tracker useless. It's true, there are a lot of open issues, but that's really the way it's always been. Some things may get overlooked, and some get bumped. The reason I brought up the bumping a while back was because the sheer magnitude of it was causing the exact problem it was meant to deal with: newer feature requests were getting pushed way down and getting lost. It was basically too big a deluge all at once. In this context, what I mentioned before about statements such as "no change is trivial" worries me because it sends a message that you're giving up on this project, or at least not feeling comfortable working with your community. I'm not giving up the project at all; but I have put site features way on the back burner. What I said was said in the context of web development, because honestly that's been my experience on average. Any time Tom and I have turned attention to the site, it's been a tremendous time suck. One change became ninety, inconsistencies appeared, and things that worked in testing would stop working again after yet another change. I still do some web work from time to time, but I take no change lightly because even things I think will be simple often turn out to be nasty. Major pushes have been known to take months, and seemingly minor ones have often turned into a week or two of site work. So what you're seeing and reacting to is my default "no" on most web features, because of the fact that web work has never been easy and it pulls time away from the software--which ultimately, users care about way more. As a general rule I'm always going to be reluctant to implement new site foo. There are some minor things I can get to here and there, however; switching to iframe embeds for YouTube comes to mind. What I'd like to do (if I'm not wasting my time) is look into the currently outstanding issues and make a list of things that could be closed or that _may_ be trivial to implement. Then we may be able to clear the list up a little. I'd be okay with that, although feature-wise I'd prefer that list be kept to software alone. Certainly I know there are a lot of feature requests, and even some bugs, that may be possible to close at this point. | |
Regarding libcurl, that's something I would definitely like to look into very soon. Not early in 510, but possibly during the 510 series as I think I could make use of some of it without needing new language elements. Stuff like SSL support could all be done behind the scenes for instance, so that kind of thing could go in during the series possibly.
| |
Honestly all I'm seeing here are reasons for you "hiring" a web guy to manage the website portion of things (and no, I'm not necessarily advocating myself). Seems like a pretty obvious division of labor there.
| |
Lummox JR wrote:
NullQuery wrote: I see... in my case I guess I'm too used to being a web developer nowadays to see how any change could be "non-trivial". =P To be honest I don't understand the point of modifying fdel()'s documentation. I don't see why it wouldn't be clear that, if you have a savefile open for a specific file, deleting the file would null out the savefile reference. That's the exact behavior I would expect.But calling del on an object will delete all references to it; it seems pretty logical that fdel() on an open file would delete open savefile references to it. Anyway this is something that AFAIK, you're the only one who ran across. Yes. Calling del on an object will delete the references. But this behavior was never mentioned for fdel. Are we to assume the behavior is the same on the sole basis that the name happens to be similar? It's true that the file being opened locks it; but since the server process owns the locks, the server can delete it. Then the way I've seen BYOND all this time is wrong. The way I see it, I'm developing a game. I have nothing to do with a server or networking or any of that stuff. I can influence it with proc calls and variables, but ultimately it's a closed component over which I have no control. But I still don't see how the behavior is an unreasonable expectation. In the current scenario the developer has to figure out why their variable is suddenly null, but if it were caught the developer would see a clear runtime error pointing out that the file was locked. I find the latter more reasonable than the former. I guess it can't hurt anything to document it, but that's been extreme low priority. I understand it's not going to be high on your priority list, but I think changes like this that would only take up a few minutes of your time should be done ASAP. It clears up the issue list so we can focus on something more important, and in most cases it'll likely fix a "paper cut" that only serves to annoy new developers that aren't familiar with how the language operates internally. As a rule no project is going to call fdel() on an open savefile, but rather will try to do all its saving in a single proc without sleeping. There's truth in that, which is why I didn't think it was that high priority myself. But it's been weeks and no update to the reference. You're on the forum regularly but you didn't manage to add a single sentence to the reference... I know it's really not that big of a deal either way, but it's weird from where I'm sitting. Another major problem: you made that decision without informing anyone that you made it. I'm not talking about the decision that was made on how fdel behaves with savefiles, but rather the decision not to update the DM Reference. I would have preferred to know this decision so I could defend it and/or mention it somewhere in The Red Book or some other place. I didn't even know about it until I looked into it, but if I'd been pressed to guess how fdel() and savefiles would interact, I'd have guessed either 1) the savefile reference would be nulled out, or 2) the fdel() call wouldn't be permitted. But in either case I'd have said that if they're interacting at all, it's a bad thing. Yeah, ideally it'd block until the savefile has been fully written, even if it means deleting it afterwards. No hard feelings at all and I'm still completely open to your suggestions. :) Thanks. :) I would kinda like to bring back the online reference, although a lot of its infrastructure was gutted with the last big forum change. I'd be open to some kind of wiki thing I guess. My main concern with such a thing would be ease of setup and maintenance, to avoid putting more time into it than necessary. In the past I developed a website called "byonddev.com" which had a wiki with BYOND authentication. I may be able to restore that, turn it into a developer resource website. I could also add functionality like an editable DM Reference and stuff like that to it. If you're up for it we could collaborate on it (seeing as BYOND would need to read the DM Reference online)? It's true, there are a lot of open issues, but that's really the way it's always been. Unfortunately so. The problem with this is that no-one knows what is being worked on and what isn't. In the past I was working on a library for SQLite support and literally one day later you suddenly added it natively. Naturally my work ended up in the bin, though at the time I did learn a little more about C/C++. Some things may get overlooked, and some get bumped. The reason I brought up the bumping a while back was because the sheer magnitude of it was causing the exact problem it was meant to deal with: newer feature requests were getting pushed way down and getting lost. It was basically too big a deluge all at once. Personally I'm confident that if those newer requests are good enough they'll appear at the top again because someone will say '+1' or offer a suggestion on them. But I can understand that it may have all come together at an awkward moment, heh. I'm not giving up the project at all; but I have put site features way on the back burner. And I hope you continue to do so! There's plenty of things that could be improved on the web end, but IMO the software/webclient should be the priority. Without developers making games a fancy website isn't going to be any good. What I said was said in the context of web development, because honestly that's been my experience on average. As I mentioned before, if you're up for it I can help out here and there. I'm good with web stuff, and I've written my own libraries to help out in this regard. I.e., automatic JavaScript compiling/minifying, LESS->CSS compiler/minifier, MVC. I think I could whip up a nice development resource site/application. What I'd like to do (if I'm not wasting my time) is look into the currently outstanding issues and make a list of things that could be closed or that _may_ be trivial to implement. Then we may be able to clear the list up a little. Alright, I'll look at the list then. | |
Keep the rants coming
| |
NullQuery wrote:
It's true, there are a lot of open issues, but that's really the way it's always been. That's one of the reasons I started doing the development news posts. I wanted people to be in on the loop regarding what I'm working on. In the past Tom and I would be fairly quiet publicly about what we were doing, and from the outside it often looks like little is being done. The news posts I do are to let people know how and where things are going. | |
