Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Naming #6

Open
luke2m opened this issue Jul 19, 2021 · 21 comments
Open

Naming #6

luke2m opened this issue Jul 19, 2021 · 21 comments

Comments

@luke2m
Copy link
Member

luke2m commented Jul 19, 2021

Will we choose a new name or continue with Brackets? I think that this project will be confused with the original Adobe project if the name remains.

@Jalkhov
Copy link

Jalkhov commented Jul 20, 2021

Here they are talking about "Ornaments", a sort of synonym or similar to Brackets, for some reason something simple like Neo-Brackets comes to mind.

@ScanuNicco
Copy link
Contributor

I think that we should keep Brackets as part of the name so that people know that this is a continuation of the original Adobe Brackets. Maybe something like LibreBrackets? I think that between that and possibly a new logo, it should be different enough.

@yogo1212
Copy link
Contributor

@luke2m my gut feeling is that a rename should wait for a while.
at the moment, being confused with the adobe project is less of a problem than being able to "catch" the people looking for brackets.

@Jalkhov the idea with "ornaments" was a stab in the dark, i prefer your proposal.

i agree with @ScanuNicco about the reasons for keeping brackets in the name - at least for now.

maybe in a year or so, if the new repo overtakes the old one in search results.

but that shouldn't stop us from collecting ideas in here :-)

@locness3
Copy link

My idea is Embrace.

@Htmlbelov
Copy link

OpenBrackets

@sprintr
Copy link
Contributor

sprintr commented Jul 22, 2021

LibreBrackets

@locness3
Copy link

GNU/Brackets

@Shakil-Shahadat
Copy link

Brackets Reborn

@Maniues
Copy link

Maniues commented Aug 5, 2021

BracketX or BrackeX

@nativeit
Copy link

Brackish

;-)

@kimdorris
Copy link

I like @Htmlbelov's OpenBrackets. Waiting is a good idea until the redux project gains momentum and Brackets popularity dies off as others have said.

Thank you to everyone working to keep Brackets alive.

I used Dreamweaver until Adobe stopped support for CFML, then I switched to Brackets. CF Builder was too expensive for me. Funny how much I miss Dreamweaver given that I hated it back when it resembled FrontPage and was only good as a WYSIWYG editor. Fireworks did a better job at slicing up the page than Dreamweaver did.

I really miss HomeSite, though. It'd be great if the new Brackets could become as popular and useful as HomeSite was back in the day.

@rileyhawk1417
Copy link

As much as theres VSCode Brackets is still better in terms of performance and live preview.

@locness3
Copy link

pls stop comparing vs code and brackets

@rileyhawk1417
Copy link

@locness3 my bad just voicing an opinion x_x

yogo1212 pushed a commit that referenced this issue Sep 24, 2021
@Thomashighbaugh
Copy link

If you want to maintain continuity of brand recognition, keeping the name and maybe jazzing up the logo is probably the best way, not to offend anyone but why did Voldemort Code do so well? The fact it was easy for the developers who would try it out to understand what it even was due to their prior experience with the full fledged Voldemort software a certain company we all know, most of you even use, that is ubiquitous in all things tech for some absurd reason.

If you change the name, all of the marketing effort of Adobe in this product is reduced to merely its code base and in terms of brand recognition you are back to square one. The code base is substantial, a certain advantage over products that are one guy's hobby project pieced together via Medium articles, sure, but it means sacrificing a substantial advantage and from what I can tell, gaining practically nothing by doing so whereas leaving the name as it was, you gain in recognition and if you manage to mend the product, the underdog boost in people's opinions of it, which itself can be quite an interest stirring thing as what happened with Voldemort Code.

Now some above suggest that Brackets at least be kept in the name, I suppose my input places me in the radical faction of that camp suggesting the name be kept and branding treated as an inherited asset. To further tease out my position, distinguishing this opinion from the opinion of the moderates wishing to keep some aspect of the name but are open to change, this still shifts the perspective of many users to do, think Voldemort Code vs. Voldemort Code OSS, the latter is known as having fewer features without a bit of magic that outside of the Linux world no one would ever bother to do. So appending to the present name, even if wholly unfair for the public to do, they will likely assume a loss of features if a blitz of Medium articles don't come out around the next release deflecting exactly that (which if necessary, I would be happy to contribute to).

The thing, in my humble opinion, it is really all dependent on and think everyone else would be better to make this call as you are all clearly far more involved than this wandering vagabond that I am, whom just stumbled into town so to speak, is does the name change increase or decrease the amount of interest developers show in the project as now these are now far more critical to the life of the project now, since without either a very passionate few or a substantial amount of people willing to take a few minutes away from the Steam window, this project is deader than fried chicken. Thus all of the projects major decisions should probably be framed around attracting more developers the way trees put out magnificent fruit of spectacular color in hopes a passing animal eats it and then later passes the seed out of themselves in a nice fertilized package and a tree can grow. I would expect that analogy to hold in the proceeding period where all of these uncertainties get ironed out. As a wise programmer once quipped, "A camel is a horse made by committee."

But let me use Github's Markdown Editor to make a few quick tables to illustrate some of the boundaries of the calculus at play in this decision as that will help those making the decision, whatever it may be, make the optimal one with as much to go on as possible available at a glance. I have tried to maintain as impartial of an approach as possible in preparing as much, but do forgive me as I am thus far unable to upload my mind to Cyberdyne's servers for use in their new Skynet Jupyter Notebook, thus am as prone to perspective bias as anyone.

Regarding a Name Change In General

Pros Cons
New, Adobe Free Identity Loss of Brand Recognition
New Logo Loss of professionally designed, tasteful logo
Potential to substantially rewrite sections for the code or break out of the confinement of reputation Loss of the positive elements of the reputation
Escaping the reputation of being extremely buggy and broken nostalgia factor reduced or lost by highlighting a loss of continuity

Topology of Opinions

Faction Perspective
Full Name Change Concerned the project will be confused with the Adobe product it was forked from and inherits its code base from
Retain Some Element of the Original Branding While desiring that it is clearly enumerated from its predecessor, retaining part of the name facilitates continuity
Change Nothing About Branding Thinks treating the branding as it was as an asset inherited is a bigger advantage than distinguishing it, which may be a double edged blade

Temporal Scope

Roll Out Pros Cons
Immediate Generate buzz now, stirring developer interest while things are fresh and hopefully attract devs to the project Potentially lost in the sea of things buzzing about presently and lacking anything to show other than the branding change
Delay Develop other, noteworthy changes to the IDE and present a whole, consistent product with the branding change potential further atrophy of interest, and potential for new software to fill vacuum present in non-terminal IDEs at the moment

Below are those things I have not seen considered but think its worth considering, as the project can hardly be all things to all people and will need to consider, the points are more limited than the realistic options, this is only meant to stir thoughts on these subjects.

Audience

| Crowd | Perspective |
| Devs | useful as dev interest translates into PRs directly, they are now that which the project lives and dies based on their fickle whims so targeting them in some way would enable a more robust project over all |
| Students, Newer Devs | Not as likely to contribute but require less, are generally less demanding and like novelty factor more. No need for it to become modal or terminal based here |

Vision for the Future

| Direction | Considerations |
| More features | Does Brackets want to closely track developer fads and newer technologies as they emerge to become the bleeding edge either in its core functionality or due to its extension ecosystem? |
| A more solid platform | Or would Brackets be better focusing on its weak points and really hammering out all of its kinks to make a rock solid text editor that can be counted on as a consistent tool in the belt of those writing their markup in HTML, CSS and the wonderfully weird world of JS? |


A Final Point from the Disgruntled Linux Dev

May I advise breaking from Adobe on the refusal to support Linux, since its not much harder to package for (especially with AppImages) than packaging for macOS with its awful walled garden or all the tedious hoops you have to jump through for Tom Riddle's OS company compliance. Its not even a matter of expertise, its really just using webpack to make a few archives and maybe writing a bit of bash shell, that the Voldemort Code crowd with their Voldemort Subsystem Linux should be more than used to these days and our lords and saviors that use mac should probably already be familiar with. I would also be more than happy to help in this process, I have done this before for a really quick markdown editor I wrote a few years back and understand Linux better than I ever wanted to.

I do wish this project the best and would be happy to contribute as it is desired or needed, let me know. I hope my thoughts on the subject, even if they immensely irritated you, inspired the sort of passionate mental grappling with the project and its future necessary to propel it into bigger and better things.

  • Thomas Leon Highbaugh

@kimdorris
Copy link

@Thomashighbaugh

New Logo Con: Loss of professionally designed, tasteful logo

Perhaps I don't quite understand this point, but to me it isn't necessarily the case that there will be a loss of a professionally designed, tasteful logo if a new logo is designed and accepted for circulation. It is possible someone in the OpenSource community is a professional designer and could potentially design an even better logo than what Adobe created. Honestly I think the Adobe Brackets logo is too simplistic and basic, despite its instant brand recognition. It's true it need not be complex and flashy, but the extant logo is a bit ho-hum. 🥱

Suggestion for new logo: <br>

Reasoning: It works for both Brackets as well as OpenBrackets and the tag is immediately recognizable to anyone with a basic understanding of HTML. I'm sure a professional designer could jazz it up a bit. I would also strongly encourage someone to look into any copyright/trademark infringement that may exist as I used to work for a (now long defunct) company that used this as their logo. I suggested it as I've always thought it was quite a clever logo.

@Maniues
Copy link

Maniues commented Oct 7, 2021

I would also strongly encourage someone to look into any copyright/trademark infringement that may exist

Are you talking about your suggestion or about actual Brackets logo?

Name "brackets" is not trademarked, nor logo is. Brackets actual logo is licensed under MIT License or it is in Public Domain, because it may be recognized as not artistic work

@ScanuNicco
Copy link
Contributor

I personally like the rounded logo that is being used as the icon of the discord server. I think it is a bit nicer but it is still very similar to the old logo.

@Abhinav1217
Copy link

@Thomashighbaugh

A Final Point from the Disgruntled Linux Dev

May I advise breaking from Adobe on the refusal to support Linux, since its not much harder to package for (especially with AppImages) than packaging for macOS with its awful walled garden or all the tedious hoops you have to jump through for Tom Riddle's OS company compliance. Its not even a matter of expertise, its really just using webpack to make a few archives and maybe writing a bit of bash shell, that the Voldemort Code crowd with their Voldemort Subsystem Linux should be more than used to these days and our lords and saviors that use mac should probably already be familiar with. I would also be more than happy to help in this process, I have done this before for a really quick markdown editor I wrote a few years back and understand Linux better than I ever wanted to.

Devs can piggyback from Apprepo's Bracket Appimage build. This person is doing social service by building Appimage from official repos for a lot of apps. Currently It is outdated because they might not be aware that project is getting continued by community, or because there is no deb or rpm release to build from. I do agree, releasing for linux is not as impossible task as it used to be, snap, flatpak, appimage resolve the multiple distro issue. There is even a github action for building appimage using docker.

  • another disgruntled linux dev.

@luke2m
Copy link
Member Author

luke2m commented Feb 4, 2022

@Abhinav1217 I will be more than happy to package in multiple formats (thinking deb,rpm, flatpak, AUR) once the port to electron is done. Unfortunately, I don’t have the skills or free time to work on that. If you are a linux dev, hopefully you can help out with that. I will make sure packaging is no issue.

@Abhinav1217
Copy link

I can do rpm, and eopkg (solus os), and I have recently learned building AppImage. From practical point of view, AppImage is secure, portable, can be auto updated, and able to run on almost all standard linux distribution. Electron-builder already support building Appimages, if needed, although I personally prefer building AppImage from rpm, or deb file.

I thought brackets was based on bracket shell, not electron, Is there plans to port it to electron?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests